Question

I am currently reading http://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

I understand the mediator pattern as some sort of object which sets up publish and subscribe functionality.

Usually I am setting up objects which already provide subscribe(), publish() methods. Concrete Objects extend this base object so that subscribe() and publish() are always registered as prototype attributes.

As I understand right the mediator pattern is used to add the publish-subscribe-methods to an object.

What is the benefit of this practice? Isn’t it a better practice to provide a base object with publish and subscribe functions than letting a mediator set up at construction?

Or have I understood the mediator pattern wrong?

Answer 1

As what I have learned from similar posts some time ago:

• The mediator pattern provides a standard API for modules to use.

  Let’s have an example:

  Your app’s thousands of modules heavily rely on jQuery’s $.post. If suddenly, your company had licensing issues and decided to move over to, for example, MooTools or YUI, would your look for all the code that uses $.post and replace them with something like MooTools.post?

  The mediator pattern solves this crisis by normalizing the API. What the modules know is that your mediator has a post function that can do AJAX post regardless of what library was used.

  //module only sees MyMediator.post and only knows that it does an AJAX post
  //How it's implemented and what library is used is not the module's concern
  
  jQuery.post   -> MyMediator.post -> module
  MooTools.post -> MyMediator.post -> module
  YUI.post      -> MyMediator.post -> module
  

• The mediator serves as the “middle-man” for intermodule communication.

  One problem in newbie JS development is when modules are interdependent. That is when:

  MyClassA.something = MyClassB.method();
  MyClassB.something = MyClassA.method();
  

  But what if something is wrong in MyClassB and the developer took it out of the build. Would you look for and strip out all code in MyClassA that uses MyClassB so that it does not break due to the absence of MyClassB?

  The mediator pattern’s publish and subscribe pattern solves this by making the module subscribe to an event instead of directly interfacing with the other modules. The mediator acts as a collection of callbacks/subscriptions that are fired when events are published.

  This “anonymous” subscribing results in partial loose-coupling. Modules would still need to know which modules to listen to or at least a set of events to listen to, but they are connected in a way that won’t result in breakage if any one of them is taken out. All they know is that they subscribed to the event and will execute when that event happens – regardless of who fires it, if it fires at all, or if the trigger exists.