What is Mediator Design Pattern?

Mediator Design Pattern, as the name suggests defines an object that mediates between other objects. It is one of the most important and widely used behavioural design pattern because it promotes loose coupling by refraining objects from communicating with each other explicitly. The mediator object does the task of mediating the information between them. You can find the usage of such a design pattern in applications that involve messaging. If a user wants to broadcast a message to other users, the objects that represent the users, communicate their way through the mediator object that keeps track of all the users and broadcasts it to them. The structure of the application could have been quite messy if there was no mediator, and every user object would have to track down every other user object for communication. The use of mediator design pattern in cases like these reduces dependencies between communicating objects, ultimately reducing coupling. In this article, we are going to define Mediator Design Pattern, mention the key participants that make up this design pattern, explain the use case with an example of mediator design pattern in java and also see when to use mediator design pattern.

What is mediator design pattern?

As mentioned in the introductory paragraph, mediator design pattern’ s intent is to define an object that encapsulates how set of objects interact with each other. It falls in the category of behavioural design pattern. Why? Behavioural Design Patterns describe the patterns of communication between objects, they are concerned with the assignment of responsibilities between objects and mediator design pattern follows the same approach.

Read: "When to Use Composite Design Pattern in Java"

In terms of real-world analogy, what can be the significance of a mediator? A traffic signal is a suitable example in this case. It mediates information to vehicles, telling them when to move, stop and wait. If there was no such mediator and every vehicle had to communicate with every other for commutation, you can imagine how dependent everything could have become? That problem is not the case today because there is a mediator (traffic signal) to signal the vehicles when to move and when not to move. Similarly, in the world of objects and in cases like the chat application a mediator design pattern provides a better solution to solve dependency issues.

Read: "All you need to know about Template Method Design Pattern"

Another example can be the Document Object Model in web browsers. Whenever we load a web page, the browser creates the Document Object Model (a tree like structure that represents every element of a web page) of that page. The web page is represented by the document object and is considered the entry point to the web page’s content. Any event emission, broadcasting or subscription happens via the document object itself. Instead of binding to the events of the individual nodes, a higher-level object (Document) is given the responsibility of notifying subscribers about interaction events. So, the document object mediates information among other elements (nodes) in a web page. You can think of the document object as the mediator and the DOM can be thought of as the simplest and common real-world glimpse of the mediator design pattern.

Read: "What is Adapter Design Pattern: A brief explanation"

Let us see a simple example of the mediator design pattern in java. We are going to use a very abstract example of a messaging service in which two users will send a message to each other. But before that, we need to introduce the key players of the mediator design pattern. They are as follows:

1. Mediator – The mediator defines an interface for communicating between objects.

2. Concrete Mediator – You can think of it as an implementation of the Mediator interface.

3. Colleague Classes – These classes are the ones that communicate information through the mediator.

For the sake of simplicity, our example is going to contain only the concrete mediator and concrete colleague class.

A simple example of mediator design pattern in java (chatroom example)

1. The Mediator (Send Message Mediator)

Fig- mediator design pattern example in java – Mediator Class

The mediator class as described previously, will mediate the information among objects. The instances of the colleague classes use the showMessage() method to send message to each other. In our example, we are simply printing the message. We could have declared this method as an interface or an abstract class but for the sake of simplicity, we have stick to concrete class example.

2. Colleague Class (User)

Fig- mediator design pattern example in java – Colleague Class

The colleague class (User) has its own version of sendMessage() that broadcasts message using the mediator’s public method. Note that, this example is not a representation of real-world chat application. Real-world applications use a lot of stuffs such as HTTP request-response cycle, web sockets, sessions etc. We are simply demonstrating how a class can be used as a common point of communication for objects.

3. Sending message via the mediator

Fig- mediator design pattern example in java – Mediator Design Pattern in action

We have used two instance of the User class here. As you can see both bob and dave objects use the same class method sendMessage() which is declared inside the mediator class to accomplish a task of sending a message. The mediator class’s method is being used by both object instances to broadcast the message.

Read: "Factory Design Patterns in Java"

What are the benefits of using the mediator design pattern?

1. The benefit of having such a design is that now if we want to add a new feature to our application, the mediator is the place where we make changes and the colleague objects can reflect upon those changes easily.

2. The maintenance of our application becomes easier as it centralizes the control logic of the application. The mediator is the centralized component in the mediator design pattern.

3. Dependency among objects reduces. A mediator promotes loose coupling between colleagues. You can think of it in this way – A mediator replaces the many to many interactions with one-to-many interactions between colleagues and the mediator.

What is the downside of using the mediator design pattern?

The downside of using the mediator design pattern can have a trade-off in complexity of the mediator itself. Making the mediator a centralized point of interaction can cause it to become a monolithic structure that itself might become hard to maintain.

Read: "Singleton Design Pattern – A thoughtful dive into Object Structures and Creation"

The summary of the Mediator design pattern discussed so far

1. When we add a mediator to our system all of the colleague objects–

Can tell their mediator when their state changes. This is in contrast to the observer design pattern in which the publisher broadcasts about state change to its subscribers. In correspondence to the mediator design pattern – the publisher can be thought of as the mediator and the subscribers as the colleagues.

Read: "Decorator design pattern in java with examples"

2. When to use mediator design pattern?

We should use the mediator pattern when – reusing an object is not feasible because it refers to can communicates with many other objects; also, we should use the mediator design pattern when we don’t want to customize a behaviour that is distributed between several classes using the method of sub classing.

Read: "Design Patterns: A quick guide to Observer pattern in Java"