Download the working example demo code in java from my GIT repository –https://github.com/premaseem/designPatterns/tree/master/ZipDownloadableProjects
Example Code Description :
1. Air Traffic Controller at air port : Flights classes have the behaviour of landing. Before landing they need to communicate to figure out if run ways is not blocker. With the same intent I have introduced a mediator class called at ATCMediator.java which will mediate the communication between the flights and assist them for landing.
2. Producer Consumer for messages: Producer and Consumer (multiple objects) relies on a mediator for coordination of exact state to proceed ahead. This is a multi treaded program with intermediatory class – Mediator.java
3. Traffic Light Signal : When one light turns On, rest other have to be turned off. If each light will communicate with another lights to changes their state then it would be highly coupled and difficult to maintain. By introducing Light Mediator which is responsible to hold object reference of all other light and communication task, the design becomes flexible and decoupled. We can add any color light and remove it when ever we want that too at run time.
Zipped code download link : https://drive.google.com/file/d/0B-9WtmpPhI4ZaU9rMnRIMjBTWFE/view?usp=sharing
Mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program’s running behavior.
Usually a program is made up of a large number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.
With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.
Before Mediator Design Pattern
So what is the problem we are trying to solve here? This complex interaction between objects creates dependency and tighter coupling. We stand for loose coupling, we want to reduce dependency as much as possible, we want more reuse.
After Mediator Design Pattern
Define an object that acts as a mediator between communicating objects thus removing the direct dependency between those communicating objects. This mediator object encapsulates the interaction information and uses it to enable communication between the objects.
The intermediate mediator object is not only to communicate between two objects, but it helps in interaction for a set of peer objects. This mediator object is like a router in networks, which is routes / controls or coordinates communication between systems.
Real-time Example for Mediator Design Pattern
Air traffic controller (ATC) is a mediator between flights. It helps in communication between flights and co-oridates/controls landing, take-off. Two flights need not interact directly and there is no dependency between them. This dependency is solved by the mediator ATC. If ATC is not there all the flights have to interact with one another and managing the show will be very difficult and things may go wrong.
Mediator Pattern Implementation
In a mediator design pattern implementation we will have
- mediator interface – an interface that defines the communication rules between objects
- concrete mediator – a mediator object which will enables communication between participating objects
- colleague – objects communicating with each other through mediator object
- Identify a collection of interacting objects that would benefit from mutual decoupling.
- Encapsulate those interactions in the abstraction of a new class.
- Create an instance of that new class and rework all “peer” objects to interact with the Mediator only.
- Balance the principle of decoupling with the principle of distributing responsibility evenly.
- Be careful not to create a “controller” or “god” object.