Mediator Pattern Using .NET
In this post, I will show how to implement a Mediator pattern using .NET/C# to help write loosely coupled code.
Join the DZone community and get the full member experience.Join For Free
Mediator pattern is a very well-known pattern in programming, and in this post, we will see what it is, what it brings to the table. A straightforward implementation to understand some of the situations where we can think of using it.
- A mediator pattern encapsulates how objects interact and communicate with each other.
- It promotes loose coupling of objects.
- It facilitates many-to-many relationships/communication as well as one-to-many.
- You can think of Mediator as a communication hub.
You can use a mediator pattern for many different use-cases. Following are a few of the requirements/situations where the Mediator pattern can help us greatly.
- Job/Task Process
- Geo-Locations / Control Centers
You can implement this pattern in a variety of ways in many different programming languages. I will be using C# in a .NET Core Console application using Visual Studio Code, but the design can be easily ported to other languages.
Implementation Using .NET Events (Control Center)
.NET Events are one way to implement Mediator Pattern and start with this example first. Later we will see another example that doesn’t use Events for its implementation.
Use-case: A control-center that receives notifications about vehicle movements.
I have simplified the requirements, and here is what we want to achieve:
Whenever a vehicle is moved, it will broadcast its location to a central hub (mediator). A control-center will also be connected to the hub, and it will receive location updates as those are broadcasted from vehicles.
In the real world, vehicles might also want to communicate with each other, or control-center personal want to communicate with all the drivers. But as long as you get the idea, you can extend this example to whole new levels. We will not implement these additional requirements today and will stick to our original basic use-case.
Here is a fundamental vehicle entity which is self-explanatory.
So, our vehicle entity has a RegNo property and CurrentLocation. With these properties, we identify a vehicle and tell about its location. Then there is a Move method in which we are just setting some random values for its location.
The only thing that remains is to broadcast this location update to central-hub, and for that, we need a Mediator. Now, let's move to build the mediator and then update the Move method to wire things up.
As mentioned above, you can think of it as a central communication hub. So, objects will communicate to this hub and can receive notifications from this hub as well. This structure keeps things loosely coupled and easy to maintain complex notifications.
Again, the code is straightforward. Mediator class is implemented as a singleton, meaning that there will be only one instance of this class in our application.
The control-center will register a generic built-in EventHandler<T> LocationChanged to receive location changed notifications.
If you wonder what an event-handler is and how they work, I wrote a few posts about these topics and can look those up to refresh some background on those topics.
Here is our LocationChangedEventArgs class:
I could have passed the Vehicle from this class because all this information is available in-vehicle entity, and that is also Ok.
Broadcast Location From Vehicles
We can now use Mediator from vehicle class (Move method) to broadcast location updates, as shown below:
Receive Notifications in Control-Center
Here is our control-center:
In the constructor, we register a handler-method to the Event raised by Mediator.
Here is the main method which initiates this demonstration:
and the output shows our mediator in action:
Mediator pattern is a behavioral design pattern, and it can help us greatly in messaging/notifications kind of scenarios while keeping objects loosely coupled. There are many different variations of this pattern, and I will write about some of those variations in the coming days. If you have any questions or comments, let me know. You can download the code from this Github repo.
Till next time, Happy Coding.
Published at DZone with permission of Jawad Hasan Shani. See the original article here.
Opinions expressed by DZone contributors are their own.