Behavioral Design Patterns- Mediator

The Mediator pattern allows for objects to communicate indirectly. Rather than having multiple dependencies and the rigid structure that follows. The Mediator pattern allows for our components to be decoupled and reusable.

The Mediator pattern sits in the middle of producer and consumer like objects. Preventing them from directly referring to one another. Thus decoupling such direct dependencies.

Take for example an air traffic controller. The Airport’s landing strip has constraints concerning where and when planes have to land. Rather than requiring planes to track the location status of other plane objects they simple notify their controller of their position and get in return from the controller availability of runway space based on consuming other colleagues positions .

In the diagram above the mediator acts as the center point of instruction. Your plane object would both be producers of locations status and consumer status. Thus allowing them to know when to land based on the the mediators supply and consumption of data.

To implement the pattern is simple. You will need to outline high level abstract on how concrete colleagues will communicate with their mediators and a colleague abstract supplying the same for the concrete mediators.

The goal of a mediator is not to be a controller, but rather to decouple our objects from one another. The mediator patten simply encapsulates the communication between objects. Similar to the Mediator pattern, the Command pattern also has sender-receivers. What separates the two is the fact that the Mediator has senders and receivers reference each other indirectly.

The Mediators’ pattern focuses on decoupling peers for one another. Choosing the ideal pattern to base your design on centers around intent. If your intent is to have many to many like relationships, but still have each object act independently, the mediator pattern may be ideal for your application.