Design Patterns Uncovered: The Mediator Pattern

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

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);
       }	

}

If we assume that we could have many different colleagues that react differently when a message is received, this pattern fits in well. For example, we could have a mobileColleague that needs to display the message differently to the desktop colleague.

public class MobileColleague extends Colleague
{
      public void receive(String message)
        {
           System.out.println("Mobile 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.

Other Articles in This Series
The Observer Pattern
The Adapter Pattern
The Facade Pattern
The Factory Method Pattern
The Abstract Factory Pattern
The Singleton Pattern
The Strategy Pattern
The Visitor Pattern
The Decorator Pattern
The Proxy Pattern
The Command Pattern
The Chain of Responsibility Pattern

Next Up

Later on this week we'll be taking a look at the Interpreter pattern.