Lots of food for thought there. Even given the event driven nature of AS3, you still have lots of possibilities for the Mediator in certain types of Flash/Flex applications. Why not use some of your background with the Mediator and enter the Golden Lunch Bucket Contest #3?

Kindest regards,
Bill

nice article.

The mediator pattern is all about communication. In your article you use the observer pattern with the mediator, which is a good implementation, but actually, they compete as ‘communication’ patterns.

Observer/event based ‘communication’ patterns provide the loosest coupling, as they imply no knowledge at all of the user/client of the object.

A mediator pattern uses knowledge about the mediator, thereby making the class that knows about the mediator tightly coupled to the mediator. Since the mediator itself is actually in most cases a very specific implementation (probably the Document class in flash, or a form of facade inside the application (a subapp), it is hard to make this pattern totally reusable. Especially when you call methods on the mediator that are mediator specific, such as “mediator.update(light, cn);”. While ‘update’ is a pretty generic name for a method, it’s still specific for this implementation with the current method signature.

I would propose to do the dependency injection to the mediator at construction time: new Colleague(mediator);, as it serves no purpose to do so later, the setter method to inject the mediator will more probably than not be non-reuasable.

Furthermore, I’d like to add that mediator is a form of doing callbacks on an object, which is just a form of delegation. Nothing new here, but it might provide a little more insight in the pattern.

Your closing comment is very true “After spending a good deal of time with this pattern, I can see its functionality as well as its limitations.” I used to work a lot with mediators, but since flash’s event driven nature in as3, it’s kind of awkward to use this design pattern as opposed to the built in event/observer style of communication in flash.

Take a look at the State Design Pattern for navigation too. Each state can be set up to affect all other states as well. In fact, that might be a good project for this blog.

Thanks for your comment,
Bill