1. Overview
In this article, we’ll have a look at the Mediator Pattern, one of the GoF behavioral patterns. We’ll describe its purpose and explain when we should use it.
As usual, we’ll also provide a simple code example.
2. Mediator Pattern
In object-oriented programming, we should always try to design the system in such a way that components are loosely coupled and reusable. This approach makes our code easier to maintain and test.
In real life, however, we often need to deal with a complex set of dependent objects. This is when the Mediator Pattern may come in handy.
The intent of the Mediator Pattern is to reduce the complexity and dependencies between tightly coupled objects communicating directly with one another. This is achieved by creating a mediator object that takes care of the interaction between dependent objects. Consequently, all the communication goes through the mediator.
This promotes loose coupling, as a set of components working together no longer have to interact directly. Instead, they only refer to the single mediator object. This way, it is also easier to reuse these objects in other parts of the system.
3. Mediator Pattern’s UML diagram
Let’s now look at the pattern visually:
In the above UML diagram, we can identify the following participants:
- Mediator defines the interface the Colleague objects use to communicate
- Colleague defines the abstract class holding a single reference to the Mediator
- ConcreteMediator encapsulates the interaction logic between Colleague objects
- ConcreteColleague1 and ConcreteColleague2 communicate only through the Mediator
As we can see, Colleague objects do not refer to each other directly. Instead, all the communication is carried out by the Mediator.
Consequently, ConcreteColleague1 and ConcreteColleague2 can be more easily reused.
Also, in case we need to change the way Colleague objects work together, we only have to amend the ConcreteMediator logic. Or we can create a new implementation of the Mediator.
4. Java Implementation
Now that we have a clear idea of the theory, let’s take look at an example to better understand the concept in practice.
4.1. Example Scenario
Imagine we’re building a simple cooling system that consists of a fan, a power supply, and a button. Pressing the button will either turn on or turn off the fan. Before we turn the fan on, we need to turn on the power. Similarly, we have to turn off the power right after the fan is turned off.
Let’s now take a look at the example implementation:
public class Button {
private Fan fan;
// constructor, getters and setters
public void press(){
if(fan.isOn()){
fan.turnOff();
} else {
fan.turnOn();
}
}
}
public class Fan {
private Button button;
private PowerSupplier powerSupplier;
private boolean isOn = false;
// constructor, getters and setters
public void turnOn() {
powerSupplier.turnOn();
isOn = true;
}
public void turnOff() {
isOn = false;
powerSupplier.turnOff();
}
}
public class PowerSupplier {
public void turnOn() {
// implementation
}
public void turnOff() {
// implementation
}
}
Next, let’s test the functionality:
@Test
public void givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff() {
assertFalse(fan.isOn());
button.press();
assertTrue(fan.isOn());
button.press();
assertFalse(fan.isOn());
}
Everything seems to work fine. But notice how Button, Fan, and PowerSupplier classes are tightly coupled. The Button operates directly on the Fan and the Fan interacts with both Button and PowerSupplier.
It would be hard to reuse the Button class in other modules. Also, if we need to add a second power supply into our system, then we would have to modify the Fan class’ logic.
4.2. Adding the Mediator Pattern
Now, let’s implement the Mediator Pattern to reduce the dependencies between our classes and make the code more reusable.
First, let’s introduce the Mediator class:
public class Mediator {
private Button button;
private Fan fan;
private PowerSupplier powerSupplier;
// constructor, getters and setters
public void press() {
if (fan.isOn()) {
fan.turnOff();
} else {
fan.turnOn();
}
}
public void start() {
powerSupplier.turnOn();
}
public void stop() {
powerSupplier.turnOff();
}
}
Next, let’s modify the remaining classes:
public class Button {
private Mediator mediator;
// constructor, getters and setters
public void press() {
mediator.press();
}
}
public class Fan {
private Mediator mediator;
private boolean isOn = false;
// constructor, getters and setters
public void turnOn() {
mediator.start();
isOn = true;
}
public void turnOff() {
isOn = false;
mediator.stop();
}
}
Again, let’s test the functionality:
@Test
public void givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff() {
assertFalse(fan.isOn());
button.press();
assertTrue(fan.isOn());
button.press();
assertFalse(fan.isOn());
}
Our cooling system works as expected.
Now that we’ve implemented the Mediator Pattern, none of the Button, Fan, or PowerSupplier classes communicate directly. They only have a single reference to the Mediator.
If we need to add a second power supply in the future, all we have to do is to update Mediator’s logic; Button and Fan classes remain untouched.
This example shows how easily we can separate dependent objects and make our system easier to maintain.
5. When to Use the Mediator Pattern
The Mediator Pattern is a good choice if we have to deal with a set of objects that are tightly coupled and hard to maintain. This way we can reduce the dependencies between objects and decrease the overall complexity.
Additionally, by using the mediator object, we extract the communication logic to the single component, therefore we follow the Single Responsibility Principle. Furthermore, we can introduce new mediators with no need to change the remaining parts of the system. Hence, we follow the Open-Closed Principle.
Sometimes, however, we may have too many tightly coupled objects due to the faulty design of the system. If this is a case, we should not apply the Mediator Pattern. Instead, we should take one step back and rethink the way we’ve modeled our classes.
As with all other patterns, we need to consider our specific use case before blindly implementing the Mediator Pattern.
6. Conclusion
In this article, we learned about the Mediator Pattern. We explained what problem this pattern solves and when we should actually consider using it. We also implemented a simple example of the design pattern.
As always, the complete code samples are available over on GitHub.