Mediator design pattern is a behavioral design pattern. Following single responsibility principle, one can distribute behavior of a system among several classes. But such a distribution can have consequences in many ways:
- An object cannot work without the support of other classes; High coupling.
- It can be difficult to change the system’s behavior in any significant way, since behavior is distributed among many objects.
Many a times when several classes are involved in communicating with each other i.e. they have many to many relationship with others classes, it is difficult to control them.
As a remedy to the aforementioned problem, Mediator pattern is widely advised .The word, Mediator, it says that it assists the parties to negotiate a settlement or follow a defined protocol. Well, you may also say the parties involved follow “No strings attached” principle. So it is the mediator who help two parties communicate or connect.
Example:
If you search internet you would probably find several examples describing Mediator Pattern. I would probably list some of them:
- Multiuser chat user chat server: here chat server plays the role of a Mediator.
- Airplane and Airport: Airplane talks to the control room only via Radar. Radar plays the role of a Mediator.
- Software development team and client (customer): Team communicates to the client through Manager and vice versa. Manager plays the role of a Mediator.
I could possibly think of a new example to describe the pattern. We, nowadays, use e-commerce website to shop online. Customers order items online and website ships those orders/items via some third party freight e.g. DHL, FedEx, Overnight, etc. Online e-commerce engine does not own freights. Both parties have a defined protocol that they follow to ship an item. e.g. they need customer name, address, phone number, item details, priority, etc.
Now let’s proceed to design a solution to the above problem without mediator:
Bad Design
Possibly we could design a system where e-commerce engines has-A (composition) freight or e-commerce is-a (inheritance) freight. There are consequences with both methodologies here. With former, it is high coupling and with latter, if website wants to outsource their freight services, it would be difficult to separate the whole freight system into a different division i.e. a lot of changes.
Good Design
From OOD perspective, online engines and freights have their dependencies (shipping) on each other. Dependencies can be avoided by encapsulating collective behavior (Protocol e.g. send/receive calls to/from partner classes) in a separate object. The object separating behavior is called Mediator object. Mediator serves as an intermediary that keeps object (Online engines and freights) in the group from referring each other explicitly. The object only knows the mediator, thereby avoiding many to many connections.
Now that we have seen possibly a good design, let’s look in to the definition of the pattern:
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction indecently. (Gamma et. al).
Mediator acts as a hub of communication for partner classes. The partner classes (Online engines and freights) communicates with each other only indirectly, through mediator. The partner classes don’t have to know about each other; all they know is the mediator.
Let’s design a solution for our problem using mediator design pattern:
![design]()
Let me here explain the classes involved in the uml diagram.
IMediator (Abstract Mediator)
It’s an abstract mediator class which Concrete Mediator should implement to communicate with partner classes. In case partner class has only one mediator, abstract mediator is not required.
FreightMediator (Concrete Mediator)
Concrete Mediator encapsulates the collective behavior of partner classes so that many to many interconnections among partner classes can be avoided. Concrete Mediator knows and maintains its partner.
Partner Classes
IFreight (abstract Freight Interface):
Abstract IFreight class contains reference to Abstract Mediator so that Concrete Freight can refer to mediator polymorphically.
- DHL, Dpd (Concrete Freight Interface): Defines an interface to communicate to Mediator.
- IOnlneEngine (Abstract Online Engine): Abstract IOnlneEngine class contains reference to Abstract Imediator so that Concrete Online Engine can refer to mediator polymorphically.
- AmazonEngine, EbayEngine (Concrete Online Engine): Each concrete engine communicates with its mediator whenever it would have anything to communicate to other colleagues or other way round.
Collaboration
Partner classes communicate through Mediator. They send and receive requests from a Mediator. The mediator encapsulates the collective behavior of partner classes.
So as to summarize, mediator is similar to façade, in that it abstracts functionality of existing classes. Whereas mediator encapsulates communication between partner classes, façade defines a simpler interface to a subsystem.