I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns Uncovered: The Mediator Pattern

04.26.2010
| 38276 views |
  • submit to reddit

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

}

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.

Tags:

Comments

Gabor Jakab replied on Mon, 2010/04/26 - 10:03am

Do you have syntax like

foreach(Colleague colleague: colleagues)

in Java? Nice article anyway, especially the Watch Out chapter is really useful...

James Sugrue replied on Mon, 2010/04/26 - 10:06am in response to: Gabor Jakab

Thanks Gabor

Yes - that foreach syntax has been in since Java 5. 

James

Wujek Srujek replied on Mon, 2010/04/26 - 10:14am in response to: James Sugrue

I think Gabor meant that you use 'foreach' instead of simple 'for' - it surely doesn't exist ;d

I love your articles on Design Patterns. Great stuff!

Igor Kuplevich replied on Mon, 2010/04/26 - 3:05pm

Thanks a lot! Great article.

Straub Edwin replied on Mon, 2010/05/03 - 8:08am in response to: Wujek Srujek

The syntax would be: for(Colleague colleague : colleagues){}

Amar Panigrahy replied on Sun, 2014/08/24 - 10:19am

Nice Article James.

Just wanted to know when to use Mediator and when to use Observer. Although definition for both patterns are different but both of these pattern intention from code is somewhat similar.

Thanks

Amar Panigrahy replied on Sun, 2014/08/24 - 10:48am

I got below description from oodesign.com:

Very good explanation

Communication between mediators and colleagues:

There are different ways to realize the communication between the colleagues and its mediator:1. One of the most used methods is to use the Observer pattern. The mediator can be also an observer and the Colleagues can be implement an observable object. Each time an change is made in the state of the observable object, the observer(mediator) gets notified and it notify all other colleagues objects.2. Alternative methods can be used to send messages to the mediator. For example a simple delegation can be used and specialized methods can be exposed by the mediator.3. In more complex implementations asynchronous messages can be added to to a message queue, from where they can be picked up by the mediator object.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.