Observer Pattern vs Mediator Pattern

Question

I did some googling and yes I know that questions about the difference between these two has been asked before on stackoverflow and all over the web. But I mostly find worded answers, which can be confusing.

My question is if anyone here can please provide two visual examples of both the mediator and observer patterns for me that can clearly demonstrate the difference between the two. In Javascript. Thank you!

Answer 1

Yes, they are distinct. I will explain by examples from real life, based on a typical single-page web application scenario. I am assuming your web page follows typical Model-View-XXX pattern, therefore you would have "views" on it. By view I understand a javascript component responsible for visual representation and associated logic of some part of your page - header, image list, breadcrumbs are all typical views.

Observer

Best used for single objects with great impact on overall site functionality. Typical example would be user settings or site configuration.

var settings = {
  fonts: "medium",
  colors: "light",
  observers: [],
  addObserver: function (observer) {
     this.observers.push(observer);
  },
  update : function(newSettings) {
     for (k in newSettings)
         this[k] = newSettings[k];
     this.fire();
  }
  fire: function() {
     var self = this;
     observers.forEach(function() { this.update(self); });
  }
}

where each view would behave somewhat like this:

var view = {
   init: function() {
      //... attach to DOM elements etc...
      settings.addObserver(this); 
   },
   update: function(settings) {
      //... use settings to toggle classes for fonts and colors...
   } 
}

Mediator

Best used when multiple parts of your site need to be orchestrated by certain logic. If you end up tracing a single user action through multiple callbacks and end up passing state via events, it probably makes sense to introduce mediators. There would be one mediator per workflow. A concrete example would be a photo upload.

var uploadMediator = {
    imageUploading: false,
    actors: {}, 

    registerActor: function(name, obj) {
       actors[name] = obj;
    },

    launch: function() {
       if (imageUploading)
             error('Finish previous upload first');  
       actors['chooser'].show();
       actors['preview'].hide();
       actors['progress'].hide();
    }

    selected: function(img) {
      actors['preview'].show(img); 
    }   

    uploading: function(progressNotifier) {
      imageUploading = true;
      actors['progress'].show(progressNotifier);
    }

    uploaded: function(thumbUrl) {
       //show thumbUrl in the image list
       imageUploading = false;
    }

}

When your page is initializing, all actors (various parts of the UI, possibly views) register with mediator. It then becomes a single place in the code to implement all the logic related to state management during the procedure.

Note: the code above is for demo purposes only, and needs a bit more for real production. Most books also use function-constructors and prototypes for a reason. I just tried to convey the bare minimum of the ideas behind those patterns.

These patterns are, of course, easily applicable on the middle tier too, eg based on node.js.