13

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!

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
Borges Diaz
  • 133
  • 1
  • 4
  • Check my answer here: https://stackoverflow.com/questions/9226479/mediator-vs-observer-object-oriented-design-patterns/51350834#51350834 – Shahar Shokrani Jul 15 '18 at 18:04

1 Answers1

11

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, e.g. based on node.js.

Alex Pakka
  • 9,466
  • 3
  • 45
  • 69
  • Wow. This has helped a ton. Thanks! – Borges Diaz Aug 21 '14 at 04:52
  • 3
    You welcome. I am not a big fan of patterns, believing that programming is an art. Art of finding best fit and of communicating it to the next programmer via the code. It is very useful to learn and understand patterns and be able to implement them. However, in practice, you end up changing them slightly to fit overall picture. If you examine popular opensource projects, patterns are almost never literally implemented. Yet bits and pieces are all over and programmers easily read and fix each others code. Nothing would change if I were to name observers listeners, for example. – Alex Pakka Aug 21 '14 at 05:42