Thanks for sharing

Well, I never said I agreed with your approach ;)

Too many people like to point out what’s “wrong” with other peoples’ code to try to validate themselves. They should be discussing what’s “right” with it to take the good ideas and make something better.

Anywho, the “traditional” Mediator enables viewview communication (instead of viewapp) which I believe is a great pattern for character interactivity where things update every “tick”. Then you can simply have the Mediator send off commands to update UI, models, etc (you never know when you’re going to need a command history) for things that update less often and need looser coupling (I guess most to least performant would be Visitor/Observer, Mediator, then Messaging. That gives me some ideas for a blog post…).

Anywho #2, I’ll let my example do the talking when I get around to it ;)

Ok, added you as a collaborator… if that’s how it works (Github/Git n00b).

Of course they are, but you and I both know even with scientific definitions + studies behind patterns, no one implements them the same. I’ve seen people treat Mediators in Robotlegs like Mediators (who’d a thunk?). Others used them in conjunction with PassiveView’s, yet gave them their own Presenters… still others who used them as SupervisingControllers… and Robotlegs Mediators. OOP Soup, yo.

Regardless, thanks for keeping me straight.

Wow, John, that’d be great! I’m sure the community would totally A) dig another example and B) appreciate another perspective that holds weight. Corroboration is one thing in inspiring confidence, and a different approach is WAY more inviting for those who wish to learn. Poor Joel had a lot of responsibility on his shoulders to do everything, sounds like I’ll get off easy. If you need check-in access or whatever let me know how to do that on Github.

Regarding third… if you say so. My initial suggestions on this were met with a ton of disdain and repulsiveness… which basically made me want to do it more.

You rock as usual!