+972 52-548-6969
Design patterns in the test of timeMediator
The mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior.
Like the Façade pattern, I can absolutely see the logic of wanting to use a mediator. It is supposed to make it easier to work with a set of objects, because it hides their interactions.
In practice, almost all known cases are bad ones. In fact, in most systems that I have seen any association of the name to the actual pattern it is supposed to represent is not very associated at all.
The differences between façade and mediator are minute, and you would think the same advice would apply. However, while you can find a lot of usages of facades (or at least things people would call facades), there are very few real world examples of mediator pattern in use. And almost all of them carry the marks that say: “Just read GoF book, @w$0m3!!!”
More posts in "Design patterns in the test of time" series:
- (21 Jan 2013) Mediator
- (18 Jan 2013) Iterator
- (17 Jan 2013) Interpreter
- (21 Nov 2012) Command, Redux
- (19 Nov 2012) Command
- (16 Nov 2012) Chain of responsibility
- (15 Nov 2012) Proxy
- (14 Nov 2012) Flyweight
- (09 Nov 2012) Façade
- (07 Nov 2012) Decorator
- (05 Nov 2012) Composite
- (02 Nov 2012) Bridge
- (01 Nov 2012) Adapter
- (31 Oct 2012) Singleton
- (29 Oct 2012) Prototype
- (26 Oct 2012) Factory Method
- (25 Oct 2012) Builder
- (24 Oct 2012) A modern alternative to Abstract Factory–filtered dependencies
- (23 Oct 2012) Abstract Factory
Comments
One example of a Mediator that we use everyday is the ASP.NET web forms page: it knows and performs operations in controls that exist inside of it. Don't you agree?
Isn't a service bus, or any kind of messaging system, a mediator? I'd also consider the events and callbacks parts of jQuery an example of the mediator pattern. I've found both to be very useful. I've also written small classes hook two services together so I can test that they're wired together correctly. Isn't that a mediator?
How about: The Messenger class of Mvvm Light? The Event Agreggator implementation of Caliburn? or this implementation in Js? http://thejacklawson.com/Mediator.js/
I think that can be very useful when you need to build loosely coupled components.
I agree with Trystan that a non-distributed message/event bus or a command queue should be considered a mediator.
Yep, the MessageBus/PubSub is a mediator, and it's commonly found in MVVM frameworks to communicate between view models. It's also used in web apps to communicate between components in a page.
I use Knockout.PostBox (https://github.com/rniemeyer/knockout-postbox) to do pub/sub in my web apps. Very slick. Components (e.g. observables) communicate by publishing messages on the mediator object, ko.postbox.
I even use it for application commands. So my Song object can simply call ko.postbox.publish("Play", this) to tell my application to start playing that song. It doesn't care who is listening for that command, thus decoupling the implementation from the usage. Works out nicely.
Guys, I don't consider message passing to be mediator. It is own separate thing.
Ayende, I would like to hear your explanation about what diferentiates Mediator and MessageBus/Event Aggregator.
Euproric, Think about the distinction between Facade & Mediator, or Stategy & State. Those are really subtle distinctions, but they need different names, to express their differences. To call MessageBus a Mediator is the same, except the gap is FAR larger.
What about the mediators in PureMvc framework in ActionScript -It mediates between UI and command -Command in turn interacts with Server via a Proxy
Chandan, I am sorry, but I am not going to even try to comment on something like that. I don't have a clue about ActionScript, far less about a specific framework in ActionScript.
Comment preview