Mediator

Motivation

When colleague objects require interaction between each other, keeping a web of references between these objects can be infeasible and messy. This is especially true when communication between objects is complex or is many-to-many.

The Mediator design pattern decouples colleague objects from one another.

It establishes a Mediator object, which:

• Has knowledge of all Colleague instances.
• Acts as a centralized dispatcher that receives notifications and passes them on all interested colleagues.

Code

public class Mediator {
    // Public accesibility to simplify example
    public Colleague colleagueA;
    public Colleague colleagueB;

    public Mediator() {
        colleagueA = new ColleagueA(this);
        colleagueB = new ColleagueB(this);
    }

    public void eventPublished(Colleague colleague) {
        if(colleague == colleagueA) {
            System.out.println("Event from ColleagueA received.")
            System.out.println("Updating interested colleagues.");
            colleagueB.update();
        }
    }
}

The Mediator instance contains references to all Colleague objects that communication needs to happen between.

When one Colleague publishes an event, the Mediator is responsible for calling the necessary operations on any other Colleague objects that must be updated.

public abstract class Colleague {
    Mediator mMediator;

    public Colleague(Mediator mediator) {
        mMediator = mediator;
    }

    public void publishEvent() {
        mMediator.eventPublished(this);
    }

    public void update() {
        System.out.println("Updating colleague.");
    }
}

Colleague instances only need a reference to the Mediator, rather than holding references to all relevant Colleague objects.

When a Colleague wants to publish an event to other Colleague objects, it sends a notification to the Mediator.

This can be done via the Observer design pattern, or it can pass itself to the Mediator, as shown in the example Colleague class above.

This allows the Mediator to examine the initiating Colleague and determine which actions need to be taken based on rules within the Mediator.

An effect of this pattern is the decoupling of Colleague objects from one another.

The Mediator object is the central location for logic detailing how Colleague objects interact with each other. This can make it easier to understand these interactions, but can also lead to a monolithic Mediator class, which can hamper maintainability and extensibility.

public class ColleagueA extends Colleague {
    public ColleagueA(Mediator mediator) {
        super(mediator);
    }

    public void publishEvent() {
        System.out.println("Publishing event from ColleagueA.");
        super.publish();
    }
}

public class ColleagueB extends Colleague {
    public ColleagueB(Mediator mediator) {
        super(mediator);
    }

    public void update() {
        System.out.println("Updating ColleagueB.");
    }
}

In this example, ColleagueA will publish an event that will trigger a response in ColleagueB.

// Client usage
Mediator mediator = new Mediator();

mediator.colleagueA.publishEvent();

// Output
// Publishing event from ColleagueA.
// Event from ColleagueA received.
// Updating interested colleagues.
// Updating ColleagueB.

Use Case

Dialog boxes can contain several different UI elements, such as drop-down lists, radio buttons, and input fields.

It's common for UI elements within a dialog box to change based on user input received from other elements.

For example, if a user selects a value from the drop-down, it might disable some radio buttons.

This is an excellent opportunity to use a Mediator.

In this case, the dialog box is the Mediator, and the Colleague objects are the UI elements contained within the dialog box.

The dialog box receives change events from UI elements, and is responsible for updating any other UI elements accordingly.

References

• Design Patterns - Gang of Four