Mediator Pattern: A Capable Underdog?

Aghh, One more design pattern blog on my feed? I bet you are thinking the same. But let me assure you, you would be gaining at least some idea of why I called it Capable and Underdog at the same time.

I would be answering basically 4 questions here which everyone would ask when learning about a new pattern: What, Why, When and How?

So let’s get started:

What?

First and foremost, the question that arises hearing about a new pattern is why?
Why do you need some new patterns in your project when you already have more than 20 well-known design patterns floating around and in a stable state for most of the project.

Well, to understand that first we need to understand what is mediator pattern?

If we go by the definition from Wikipedia, it says:

“the mediator pattern defines an object that encapsulates how a set of objects interact.”

Over the head huh? Don’t worry.

As the name implies, the Mediator plays an intermediatory role to mediate. But mediate between whom? You guessed it right. Between classes. In other words, it provides a unified and single entity to communicate between classes. Let’s make it simple for now, it mediates between the core API Actions and the respective business logic they communicate to. So, it’s a behavioural pattern.

You would immediately ask, why do we need a mediator when we can already communicate between classes very easily by using plenty of other design patterns, to answer that, let’s move on to the next topic.

Why?

Imagine the Airport to be your application and you need to manage the air traffic.

Imagine if there was no Air Traffic Controller on the ground and planes needed to manage the altitudes and speeds by themselves, by interacting with dozens of other aeroplanes nearby?

It would create a mess, wouldn’t it?

Most of the traditional design patterns work on dependencies. Let’s say there are 3 classes that depend on 3 different classes to execute their business logic. What we do traditionally is resolve dependencies of the classes it consumes. Which makes the interaction many to many in a way. Which creates a spaghetti of dependencies.

Now imagine you need to decouple or change the interaction of some of the classes?

That’s where the mediator comes into the picture.

What it does is, basically take care of interactions.

Which solves several issues:

1. Direct/Tight communication between classes.

2. Handles complex dependency management.

3. Allows us to easily modify any interactions between the classes.

The scenario from above will now look like this in mediator pattern:

It's easily observable that it not just looks clean but also provides a unified interface to manage the interactions.

Ok, so now that we know what it is and why it was introduced, let's check some use cases on when to use it and when not to use it.

When?

Simply put, we can use a mediator pattern when you need to get out of dependency entanglement. When you have so many classes which are dependent on one another, managing dependencies create a headache.

We can use it when we need to easily change the behaviour of how classes interact between themselves, when we need to have an ATC kind of single entity to manage the interactions and when we need to encapsulate the objects being communicated such that only a single entity knows the dependencies between classes.

Of course, it’s not perfect. It comes with a price.

As with all other single entities, it’s prone to fail. A complex mediator with too many dependencies on it may become a single point of failure. So better not complicate it.

Now let's jump on to How we can use it?

How?

Don't worry, I won't be pasting the whole solution here. You can check out multiple examples of such projects on GitHub like this one here.

But to put it in basic context, you can install and configure MediatR Nuget Package, Create models and handlers pertaining to actions/workflows, and then use it in actions by sending the request to the mediator.

Mediator with CQRS

If you have visited the GitHub repo from above, you would have seen the term CQRS-Mediator Pattern. CQRS and Mediator are often used interchangeably which is somewhat incorrect.

Both have different use cases and problems to solve, but combining both is where magic is. The Nuget MediatR facilitates the use of both patterns, which is one of the reasons why these terms are used interchangeably. Learn more on CQRS here.

Capable Underdog?

Till now, we know why it's capable, but why it's still an underdog?

Unfortunately, there is no certain answer to the question, but in my opinion and observation, the reason would be that many existing projects use widely acceptable design patterns like singleton and factory patterns. But It’s evident that the use of the Mediator Pattern is accepted and growing especially in new solutions industry-wide.

Happy Learning!!!