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.
-
-
-
-
- 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.
-
-
-
-
- class DevTeam: Team
- {
- public DevTeam(string name): base(name)
- {}
- public override void ReceiveMessage(string from, string message)
- {
- base.ReceiveMessage(from, message);
- }
- }
-
-
-
-
-
- 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.
-
-
-
- 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.
-
-
-
- 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.