Mediator Pattern

Challenge

You are working on an Airline application managing flight validations. As you might know before taking off the flight, it goes through a series of checks ensuring the health of each component, the fuel level etc.

Our Flight class contains the following component classes

• Engine
• Wheels
• Cockpit
• Aviation

Each of the component class will be having a method named Start(). On invoking the method, it will ensure that the current state of component is valid through a method named IsReady(). If the IsReady() method returned true, the component class checks the other component IsReady() method. For example the Engine class ensures the Wheels and Aviation is in valid statue by using the IsReady() method of Wheel and Aviation respectively. The Cockpit in turn checks itself, Engine and the Aviation status. So there exists a coupling between the classes and code duplications. The scenario will become worse on introducing new components as classes.



How to make the code better?

Definition

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Implementation

We can improve the above situation by introducing the Mediator pattern. Through the introduction of Mediator the component classes won't talk to each other. All the components communicate to a new Mediator class. The advantages are:

• Loosely coupled components
• Centralized Management
• More Flexibility in changing code

The new approach will look like below:



Here the component parts will communicate with the Mediator class for providing the ready signal to proceed with.

Classes

Following are the classes associated with the new implementation using Mediator Pattern.

public class FlightMediator
{
    private Engine _engine;
    private Aviation _aviation;
    private Wheels _wheels;
    private Cockpit _cockpit;
 
    public FlightMediator(Engine engine, Aviation aviation, Wheels wheels, Cockpit cockpit)
    {
        _engine = engine;
        _aviation = aviation;
        _wheels = wheels;
        _cockpit = cockpit;
    }
 
    public bool IsReady()
    {
        return _engine.IsReady() && _aviation.IsReady() && _wheels.IsReady() && _cockpit.IsReady();
    }
}
 
public class Engine
{
    public void Start()
    {
    } 
    public bool IsReady()
    {
        return true;
    }
}
 
public class Aviation
{
    private int _FuelLevel = 1000;
 
    public bool IsReady()
    {
        return _FuelLevel > 5000; // Returns false as not enough fuel
    }
} 

public class Wheels
{
    public bool IsReady()
    {
        return true;
    }
}
 
public class Cockpit
{
    public bool IsReady()
    {
        return true;
    }
}

Please note that the Aviation class returns false for the IsReady() method. The FlightMediator constructor takes all the component classes as inputs. The IsReady() method checks all the associated component's IsReady() method to ensure validations are right.

On running the Windows Forms application, you can see the following screen.



Clicking on the FlightMediator button you can see the color changing to red as the status returned is false.



Summary

In this article we have explore the Mediator pattern. The example is provided in a simple problem scenario, but the real world problems will be much complicated. For example a Wizard Page Framework where each page has to think about the previous and next pages could be made better using the Mediator pattern. The associated source code is attached with the article.