Introduction
I’ve previously written about Mediator pattern and how it encapsulates object’s interaction and communication. This pattern promotes loose coupling between software components. It acts as a communication hub and it facilitates one-to-many, many-to-one and many-to-many communications.
We than saw an example of Vehicles Control Center where vehicles position is communicated to control center. We implemented a basic mechanism where many vehicles were broadcasting to control center. You can check this post for the details.
Today, we will build upon those learning and see couple of more examples to solidify our understanding.
Chat Room Use Case
This is a very common example and there are many different techniques to build this solution. However, for our demo purposes, I dumbed down the requirements and solution to keep focus on mediator and object’s communication.
In this use case, we have different teams/groups of persons and they need to communicate with each other.
Following diagram shows the relationship b/w entities and how different entities interact with each other.
Mediator
ChatRoom (Abstract Mediator)
Here is the abstract mediator class ‘ChatRoom’
We will see details later, but in general, Colleagues will use Register method to join the chat-room and they will Send method to broadcast messages to other colleagues.
GeneralChatRoom (Concrete Mediator)
Following is the concrete implementation of the mediator.
As you can see Register method is used for bi-directional referencing purposes.
Send method is broadcasting to every colleague in the members list. So, kind of a public message.
Now, lets turn our focus to colleagues next:
Colleagues
Following is the abstract class which models a ChatRoomMember. It has a Name Property and a reference to the mediator (we sat the mediator property by calling SetChatRoom in the Register method in mediator itself).
Then we have two methods, one for sending and the other one for receiving messages.
Abstract Colleague
Concrete Colleagues
Here we have two concrete colleagues Developer and Tester. You can add more types as you see fit.
The implementation is very basic and following code shows the Override Receive method in Developer class to illustrate that you can have different handling mechanism for different type of colleagues, if you want.
However, for Sending messages, we will be using the default implementation from abstract colleague.
Application
Here in the Main method where we wired-up everything together.
As you can see that the application code
- Setup a chat-room.
- Then create and register members.
- Once members are registered, they can communication by sending a message.
- Message are sent by chat-room(mediator) to all the members(colleagues).
The following output shows that message was received by every colleague. However Developers are processing the messages slightly different:
Send Message to a Particular Member
What if we want to send message to a particular type of team member (such as developer or tester etc.) . Let’s see how to implement this:
I’ve added a new method to mediator as shown below:
here the implementation of this method in concrete mediator:
we are using LINQ’s OfType member, which Filters the elements of an IEnumerable based on a specified type.
following is the method for the colleagues:
and last but not least, here is the usage code of this function:
and here is the output of this method call:
As you can see this time, the message is sent to only Testers.
So, this was a very simple implementation of chat-room system. Though its not close to real world application and shall be used for demo purposes only 🙂
Location Proximity
For another example of mediator pattern, I have already provided the code for this demo. Following is the function you can call from the main method:
I will not go into much details. This example is very similar to control-room demo. Here Marker (colleague) represent a Vehicle kind of entity which has LocationData and then broadcast this data to other colleagues via a mediator.
Here is the output of this code:
Long GUID strings represents individual marker. So marker-1 is broadcasting its location and marker-2 is receiving and processing the location.
If we have more markers, then they all will be notified. Once a marker receive location data from other marker, it can match it with its own location data to do some proximity calculations. You can find online many good algorithms and code sample for such calculations..
You can check the source-code for implementation details and let me know if you have some questions.
Summary
In this post, we saw few more examples of Mediator pattern. Its a very powerful pattern and help keep your code structure understandable.
You can get the source code from this git repository.
Let me know if you have some questions or comments. Till next time, happy coding.