Today’s pattern is the Mediator pattern, used to handle complex communications between related objects, helping with decoupling of those objects.
Mediator in the Real World
An airport control tower is an excellent example of the mediator pattern. The tower looks after who can take off and land – all communications are done from the airplane to control tower, rather than having plane-to-plane communication. This idea of a central controller is one of the key aspects to the mediator pattern.
Design Patterns Refcard
For a great overview of the most popular design patterns, DZone’s Design Patterns Refcard is the best place to start.
The Mediator Pattern
The Mediator pattern is known as a behavioural pattern, as it’s used to manage algorithms, relationships and responsibilities between objects.. The definition of Mediator as provided in the original Gang of Four book on Design Patterns states:
Allows loose coupling by encapsulating the way disparate sets of objects interact and communicate with each other. Allows for the actions of each object set to vary independently of one another.
The following diagram shows how the mediator pattern is modelled.
The Mediator defines the interface for communication between Colleague objects. The ConcreteMediator implements the Mediator interface and coordinates communication between Colleague objects. It is aware of all the Colleagues and their purpose with regards to inter communication. The ConcreteColleague communicates with other colleagues through the mediator.
Without this pattern, all of the Colleagues would know about each other, leading to high coupling. By having all colleagues communicate through one central point we have a decoupled system while maintaining control on the object’s interactions.
When Would I Use This Pattern?
The mediator is a good choice of pattern when the communication between objects is complicated, but well defined. When there are too many relationships between the objects in your code, it’s time to think of having such a central point of control.
An observer based variation of the mediator pattern is used in Java Message Service (JMS) implementations, which allows applications to subscribe and publish data to other applications. This is a common combination of patterns that makes sense.
So How Does It Work In Java?
Here we’ll use the Mediator pattern in the context of a chatroom application. First we’ll define an interface for our mediator
//Mediator interface
public interface Mediator
{
public void send(String message, Colleague colleague);
}
While we described the Colleague as an interface above, it’s more useful to use an abstract class in this case:
//Colleage interface
public abstract Colleague
{
private Mediator mediator;
public Colleague(Mediator m)
{
mediator = m;
}
//send a message via the mediator
public void send(String message)
{
mediator.send(message, this);
}
//get access to the mediator
public Mediator getMediator()
{
return mediator;
}
public abstract void receive(String message);
}
Now let’s create our concrete mediator implementation
public class ApplicationMediator implements Mediator
{
private ArrayList<Colleague> colleagues;
public ApplicationMediator()
{ colleagues = new ArrayList<Colleague>();}
public void addColleague(Colleague colleague)
{ colleagues.add(colleague);}
public void send(String message, Colleague originator)
{
//let all other screens know that this screen has changed
for(Colleague colleague: colleagues)
{
//don't tell ourselves
if(colleague != originator)
{
colleage.receive(message);
}
}
}
}
Finally we’ll create one concrete colleage.
public class ConcreteColleague extends Colleague
{
public void receive(String message)
{
System.out.println("Colleague Received: " + message);
}
}
Here’s a client that drives the entire application:
public class Client
{
public static void main(String[] args)
{
ApplicationMediator mediator = new ApplicationMediator();
ConcreteColleague desktop = new ConcreteColleague(mediator)
ConcreteColleague mobile = new MobileColleague(mediator)
mediator.addColleague(desktop);
mediator.addColleague(mobile);
desktop.send("Hello World");
mobile.send("Hello");
}
}
Watch Out for the Downsides
While this pattern aims to reduce complexity, without proper design, the Mediator object itself can become very complicated itself.The Observer pattern could help here, with the colleague objects dealing with the events from the mediator, rather than having the mediator look after all orchestration.
Find Out More
