Design Patterns Simplified: Mediator

I am here to continue the discussion around Design Patterns. Today we will go through one of the behavioral design patterns called Mediator.

Links to previous posts:

Before talking about its implementation let’s begin with defining it.

As per the GOF guys, Mediator pattern is defined as follows:

“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.”

Well! Let’s understand what they mean and where this pattern can fit.

As the name suggests, Mediator pattern is used to enable interactions between source and target objects. It introduces a mediator object between source and target to avoid having explicit or direct references.

In a scenario when a lot of combinations take place between source and target and the number of interacting objects are growing over time, it becomes difficult to maintain code, especially for any new change.

Mediator pattern helps in such cases by encapsulating the communication logic in mediator object and thus supporting clean and loosely coupled design.

Mediator pattern has some key components as follows:

Mediator
Defines an interface to facilitate communication among Colleague objects.
ConcreteMediator
Implements Mediator and coordinates with colleague classes.
ColleagueInterface
Interface or abstract class that defines common methods and properties to interact with colleagues.
ColleagueClasses
Concrete colleague classes that are used by mediator.

How Mediator pattern works

Let’s understand this by a simple example.

We will start by defining Colleague abstract class. We can also use interface but I have taken abstract class to reuse properties.

///<summary>
/// Abstract Colleague class
///</summary>
abstract class Team
{
private string _name;
public Team(string name)
{
_name = name;
}
public string Name
{
get
{
return _name;
}
}
public MeetingRoom MeetingRoom
{
get;
set;
}
public void SendMessage(string to, string message)
{
MeetingRoom.SendMessage(_name, to, message);
}
public virtual void ReceiveMessage(string from, string message)
{
Console.WriteLine("Message from {0} to {1}: {2}", from, _name, message);
}
}

Now let’s create a couple of concrete classes as follows.

///<summary>
/// Concreate Colleague class
///</summary>
class DevTeam: Team
{
public DevTeam(string name): base(name)
{}
public override void ReceiveMessage(string from, string message)
{
base.ReceiveMessage(from, message);
}
}
///<summary>
/// Concreate Colleague class
///</summary>
class TestTeam: Team
{
public TestTeam(string name): base(name)
{}
public override void ReceiveMessage(string from, string message)
{
base.ReceiveMessage(from, message);
}
}

The time has come to create Mediator objects. Let’s create interface first.

///<summary>
/// Mediator Interface.
///</summary>
interface IMeetingRoom
{
void Register(Team team);
void SendMessage(string from, string to, string message);
}

In the interface above you can see that Register method is holding the reference of the colleague class (i.e. Team).

Now we will create concrete mediator class that will be used to establish the communication among colleagues.

///<summary>
/// Mediator concreate class.
///</summary>
class MeetingRoom: IMeetingRoom
{
private List<Team> _teams = new List<Team>();
public void Register(Team member)
{
_teams.Add(member);
member.MeetingRoom = this;
}
public void SendMessage(string from, string to, string message)
{
Team team = _teams.Where(t => t.Name == to)
.First();
if (team != null)
{
team.ReceiveMessage(from, message);
}
}
}

As you can see above in the MeetingRoom class we have created a collection to store teams while registration and same collection is used to provide appropriate team object in the SendMessage method. Subsequently team object is used to invoke ReceiveMessage dynamically or in polymorphic fashion.

Now let's see how client uses the setup created so far.

public class Program
{
static void Main()
{
Console.Title = "Mediator pattern Demo";

Team seTeam = new DevTeam("SETeam");
Team dbTeam = new DevTeam("DBTeam");
Team sysTestTeam = new TestTeam("SysTestTeam");
Team intTestTeam = new TestTeam("IntTestTeam");

MeetingRoom meetingRoom = new MeetingRoom();
meetingRoom.Register(seTeam);
meetingRoom.Register(dbTeam);
meetingRoom.Register(sysTestTeam);
meetingRoom.Register(intTestTeam);

seTeam.SendMessage(sysTestTeam.Name, "Hello System Testing Team!");
dbTeam.SendMessage(intTestTeam.Name, "Hello Integration Testing Team!");
seTeam.SendMessage(dbTeam.Name, "Hello Database Team!");
sysTestTeam.SendMessage(seTeam.Name, "Hello System Engineering Team!");

}

Output

As you can see that first we are creating colleague (i.e. Team) objects and then registering them into Mediator (i.e. MeetingRoom)

Summary:

In the article, we have gone through what mediator pattern is and where it should be used. We have also seen an example to understand how to use it. Please don’t confuse between Mediator pattern and Adapter as the purpose or intent of both the patterns are different. Adapter pattern at one side used to make interactions between two incompatible components whereas Mediator pattern simplifies the complexity involved in the communication of various components.

You can also download the attached demo project (MediatorPatternDemo.zip) to go through the full source code referred to in the article.

Hope you have liked the article. I look forward for your comments/suggestions.

12 Comments

Join the conversation! Your thoughts help the community grow.

Prakash Tripathi10y ago
Thnx Santhakumar.
Santhakumar Munuswamy10y ago
Nice share
Prakash Tripathi10y ago
Thnx Grzegorz.
Prakash Tripathi10y ago
Thnx Vignesh.
Prakash Tripathi10y ago
@Maruthi..I don't see any issue if user implements both the methods as both methods have significance.
Grzegorz Ogrod10y ago
Really good article! Why I found today, not earlier? :)
Vignesh Mani10y ago
Good one
Maruthi Palllamalli10y ago
You shouldn't use interface for it. Because it is user choice - if we use interface surely implement both register() and sendmessage() functionalities. Hopefully it's denied
Prakash Tripathi10y ago
@Maruthi, you may use abstract class as well. However since mediator class would be just one, having interface as base looks ok.
Maruthi Palllamalli10y ago
I am having one question in this your design pattern that is about mediator(interface IMeetingRoom). Here your mediator gives restriction to implementation. Why should i need to implement both Register( ) and sendmessage( ). You shouldn't give any restriction and should use abstract class instead of interface for mediator. Interaction should be in-dependable.
Prakash Tripathi10y ago
Thnx Raja.
Raja10y ago
Good One...