Mediator Design Pattern Using C#

For this process, we will be writing the code in various steps and refer to them as different processes. But during this time, we need to keep in mind that all the communication is to be done through the mediator that is either for sending or receiving the response from the two components, in other words the clients and the dev teams.

A very important key to this process is that the mediator contains the reference of both the interacting components within itself and both the components will receive the reference to the mediator at run-time, in order to send/receive the messages from each other. The client and dev-team classes will have the reference of the mediator, through their base abstract classes.

Now, we will be writing the step based code.

Step 1

The requirements are sent by the client to the mediator and the mediator forwards the requirements to the development team.

In this process, our client will send the requirements to the mediator and the mediator will forward them to the development team. Based on this concept, we have a method to send the requirements to the mediator in the client abstract class.

Step 1.1

The client abstract class will receive a reference of the mediator. Using this reference, the requirements will be handed over to the mediator, by calling the ReceieveRequirementsFromClient() method in the mediator.

Step 1.2

The Mediator will further pass these to the DevTeam, using the reference of the DevTeam it holds, by calling the method ReceieveRequirementsFromMediator(client). This method is in the DevTeam class. The details received by the dev-team, will be displayed on the screen. See the code below.



Our client code to start the process will be like the following.



How Step 1 works

To start with the process, a new mediator reference is created, and will be given to the dev and client classes, to allow them to use it for sending the messages.

At the same time, the Mediator class will be receiving the references of the client and dev teams to complete the communication process. We can see here that none of the client and dev team classes interact with each other directly. This results in a loosely-coupled system.

Step 2

The DevTeam sends queries to the mediator and the mediator forwards them to the clients.

In this step, the dev-team will send the query to the mediator and the mediator will forward the query to the client. Like the code above, the dev-team will have a method in its abstract class to forward the query to the mediator.

Step 2.1

The same as above, the Dev-team will receive the mediator reference, through its dev-team abstract class. Using this reference, it will call the ReceiveQueryFromDevTeam method of the mediator.

Step 2.2

The Mediator has the reference to the Client class. The Mediator will use this reference to call the ReceiveQueryFromMediator method of the client class. This method will simply print out the details it has. See the code below.



How Step 2 works ?

Since we have already set the reference of the mediator for the client and dev-team classes and references of these classes for the mediator in Step 1, we simply need to call the SendQueryToMediator() of the dev-team class. So the client code will be:



With this structure in place, if we need to add one more dev-team or one more client, we simply need them to inherit from their respective base classes and set the appropriate references in the client code to get them working. So with this kind of code, we avoid each class having references to other class directly. This not only avoids the complexity of managing the objects and their references, but also promotes a loose coupling. Otherwise, when you add more clients and dev classes, without a mediator, each of these classes will have the references of the other concrete classes.

Mediator vs Adapter vs Bridge pattern

At the start, we explained various patterns that have quite similar names as this pattern. Its the main purpose for which these patterns are used, distinguish them. Let's explain briefly about their objectives.

The Adapter Pattern acts as an intermediate between two components, that cannot interact with each other directly. There is no other reason to do this. For example, a legacy code or a third-party component that needs to be integrated with your new implementations will require such a pattern to be used.

The purpose of a Bridge Pattern is to provide different implementations and each of these implementations can be used in various ways. This is done using the abstract components. For examle, send an SMS or email notification to a user and send them in various ways like using web-service or third-party tools.

The purpose of the Mediator Pattern is to manage the complexity of the system by handling how they interact with each other. Otherwise, each of these classes will have references to the other classes in order to interact, when required. This would result in a spider web type system classes. So this can be avoided by using the Mediator Pattern.

Hope you enjoyed reading this article.