Coding Guru

Code never does the mistake, we make the mistakes in the code. Think, Imagine, Phrase and then Code.

The Mediator Pattern

Mediator pattern suggests a loosely coupled design by keeping the objects from referring to each other explicitly, and lets the developer to vary their interactions independently.

The Mediator Pattern uses a single shared subject which handles the communication with multiple objects. And this subject is known as mediator.


The mediator pattern provides central authority over a bunch of objects by encapsulating how these objects interact. This model is beneficial for situations where there's a necessity to manage complicated conditions in which each object is aware of any update in another object within the bunch.

"Understanding the similarities and differences between an event aggregator and mediator is important for semantic reasons."
- Derick Bailey

The mediator patterns are helpful in the development of complicated modules. For example a page in which you enter choices to make a flight reservation. Mediator rule would be: you need to enter a legitimate departure date, a legitimate return date, the return date must be after the departure date, a legitimate departure airport, a legitimate arrival airport, a legitimate number of travelers, and then the Search button must be activated.

Graphical Representation




Participants

The participating objects in this pattern are:

  • Mediator -- In sample code: Chatroom
    • it defines the interface for communication with Colleague objects
    • it maintains references with Colleague objects
    • it manages the central control over the operations
  • Colleagues -- In sample code: Participants
    • objects which are mediated by the Mediator
    • each instance holds a reference of the Mediator

Sample code

In the example below we have four participants which are joining in a chat session by registering with a Chatroom (the Mediator). Each of the participants is represented by the Participant object. The participants send messages to each other and Chatroom handles the message routing


    
var Participant = function (name) {
this.name = name;
this.chatroom = null;
};

Participant.prototype = {
send: function (message, to) {
this.chatroom.send(message, this, to);
},
receive: function (message, from) {
log.add(from.name + " to " + this.name + ": " + message);
}
};

var Chatroom = function () {
var participants = {};

return {

register: function (participant) {
participants[participant.name] = participant;
participant.chatroom = this;
},

send: function (message, from, to) {
if (to) { // single message
to.receive(message, from);
} else { // broadcast message
for (key in participants) {
if (participants[key] !== from) {
participants[key].receive(message, from);
}
}
}
}
};
};

// log helper

var log = (function () {
var log = "";

return {
add: function (msg) { log += msg + "\n"; },
show: function () { alert(log); log = ""; }
}
})();

function run() {
var yoko = new Participant("Yoko");
var john = new Participant("John");
var paul = new Participant("Paul");
var ringo = new Participant("Ringo");

var chatroom = new Chatroom();
chatroom.register(yoko);
chatroom.register(john);
chatroom.register(paul);
chatroom.register(ringo);

yoko.send("All you need is love.");
yoko.send("I love you John.");
john.send("Hey, no need to broadcast", yoko);
paul.send("Ha, I heard that!");
ringo.send("Paul, what do you think?", paul);

log.show();
}



Advantages

  • It reduces the communication relationship from "many-to-many" to "many-to-one"
  • Helps us to pinpoint the dependencies
  • Very good with decoupling of objects which promotes the smaller and reusable components

Disadvantages

  • Introduces a single point of failure
  • When modules communicate forth and back by using the mediator pattern , it becomes cumbersome which usually results in a performance hit. It's best if the mediator is only used for the coordination related actions across multiple features, not for the communication within individual features; keep the airways clean!

Loading