Friday, May 20, 2011

Mediator pattern

Define an object that encapsulates details and other objects interact with such object.The relationship are loosely decoupled.

Wikipedia Says:
Mediator Pattern is a software design pattern that provides a unified interface to a set of interfaces in a subsystem.This pattern is considered a behaviour pattern due to the way it can alter the program's running behaviour.

Usually a program is made up of a (sometimes large) number of classes. So the logic and computation is distributed among these classes. However, as more classes are developed in a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.

With the mediator pattern communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.
Mediator class promotes looser coupling between a number of other classes.It consists of a mediator class that is the only class that has detailed knowledge of the methods of other classes.

Promotes the many-to-many relationships between interacting peers to "full object status".

When to use Mediator Pattern?

  • Use the Mediator Pattern to centralize complex communications and control between related objects.
  • Mediator is commonly used to coordinate realted GUI components.


  • Increases the reusability of the objects supported by the Mediator by decoupling them from the system.
  • Simplfies maintenance of the system by centralizing control logic.
  • Simplifies and reduces the variety of messages sent between objects in the system.
  • Partition a system into pieces or small objects.
  • Centralize control to manipulate participating objects.
  • Most of the complexity involved in managing dependencies is shifted from other objects to the Mediator object.This makes other objects easier to implement and maintain.


  • A drawback of mediator pattern is that without proper design, the Mediator object itself can become overly complex.

Mediator defines an object that controls how a set of objects interact.Loose coupling between collegue objects is achieved by having collegues communicate with the Mediator,rather than with each other.
Let us look at an example...

Example Code for Mediator Pattern

In Outlook we can create some rules and alerts. Similarly for gmail we can have filters.
We can have rules like
FromRule : If a mail comes from xxx, send it to yy folder.
ToRule : If my name is in To list of the received mail, send it to yy folder.
CcRule: If my name is in Cc list of the received mail, send it to yy folder.

Let us look how we can implement the above through Mediator pattern.

So lets say we are providing these rules. So first we create a basic Rule class, which is base class of all these rules.


public class Rule {
private String text;
private Boolean isActivated=Boolean.FALSE;

public Boolean getIsActivated() {
return isActivated;
public void setIsActivated(Boolean isActivated) {
this.isActivated = isActivated;
public String getText() {
return text;
public void setText(String text) {
this.text = text;


Now these rules need command to be executed

public interface Command {
void execute();

Getting the rules

public class ToRule extends Rule implements Command {

RuleMediator mediator;

ToRule(RuleMediator mediator) {
this.mediator = mediator;

public void execute() {


public class CcRule extends Rule implements Command {

RuleMediator mediator;

CcRule(RuleMediator mediator) {
this.mediator = mediator;

public void execute() {


Mediator class

public class RuleMediator {

FromRule fromRule;
ToRule toRule;
CcRule ccRule;

void selectFromRule(FromRule fromRule) {
this.fromRule = fromRule;

void selectToRule(ToRule toRule) {
this.toRule = toRule;

void selectCcRule(CcRule ccRule) {
this.ccRule = ccRule;

void createFromRule() {
fromRule.setText("If a mail comes from xxx
send to yy folder..."

void createToRule() {
toRule.setText("If my name is in To list,
send to yy folder..."

void createCcRule() {
toRule.setText("If my name is in Cc list,
send to yy folder..."


Mediator Demo

public class MediatorDemo {

public static void main(String[] args) {
RuleMediator mediator = new RuleMediator();
FromRule fromRule = new FromRule(mediator);
ToRule toRule = new ToRule(mediator);
CcRule ccRule = new CcRule(mediator);



System.out.println("from Rule is enabled
--> "
System.out.println("to Rule is enabled
--> "

Related Patterns

Facade: which abstracts a subsystem to provide a more convenient interface,and its protocol is uni-directional,whereas a mediator enables co-operative behavior and its protocol is multidirectional.
Command: Which is used to coordinate functionality.
Observer: which is used in mediator pattern to enhance communication.

Rules of Thumb

Chain of Responsibility,Command,Mediator and Observer,address how you can decouple senders and receivers,but with different trade-offs.Chain of Responsibility passes a sender request along a chain of potential receivers.Command normally specifies a sender-receiver connection with a subclass.Mediator has senders and receivers reference each other indirectly.Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.[GoF, p347]
Mediator and Observer are competing patterns.The difference between them is is that Observer distributes communication by introducing "observer" and "subject" objects,whereas a Mediator object encapsulates the communication between other objects.We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.[GoF, p346]
On The other hand Mediator can leverage Observer for dynamically registering collegues and communicating with them. [GoF, p282]
Mediator is similar to Facade in that it abstracts functionality of existing classes.Mediator abstracts/centralizes arbitrary communication between colleague objects,it routinely "adds value",and it is known/referenced by the collegue objects.In contrast,Facade defines a similar interface to a subsystem,it doesnot add new functionality,and it is not known by the subsystem classes.(i.e a uni-directional protocol where it makes requests of the subsystem classes.(i.e it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice-versa.) [GoF,p193]

No comments:

Post a Comment