Design Patterns: Mediator

Mediator pattern belongs in the family of Behavioral Patterns. It contains the entire logic of how objects interact with each other. So, it helps us decouple objects.

What’s the problem

In case we have many objects that interact with each other, we end up with a very complex and non maintainable code. That’s why it is a good case to use Mediator design pattern.

There are many times that we have interaction among objects. We usually create a sufficient amount of objects allowing to communicate with each other with the intention of building entities which act together for a specific reason.

When something happens to an object then another one has to do something or change it’s behavior.

Building a complex code allowing many objects (2 or more) to communicate with each other, you will end up with a spaghetti code, non maintainable, and you will face a nightmare every time you want to find and fix a bug or to enhance the code.

This problem increases if you normally have a back and forth and a complex interaction.

How do I solve this problem

The solution comes using Mediator pattern. This pattern allows you to keep the whole logic of communication in one place (object) and every object used to interact with other objects now interacts only with the one which is aware of how to act in every occasion.

So, we can understand very quickly that objects are decoupled. The code is more simple than it used to be. That’s exactly what we try to achieve using OOP and design patterns.


Using Mediator pattern and keeping the whole interaction among objects in one place (object) means that we are going to move complexity from one place to the other.

It is very easy to turn Mediator pattern into a mess if you don’t separate objects appropriately. Even if you want to use the same objects but somehow differently, you have to keep each behavior in separate mediator objects.

So, there is a need to simplify mediator if necessary.

How do I code the Mediator Pattern

It is really easy to write code with mediator pattern.

We start with classes which encapsulate mediator and instead of interacting with each other, they interact with mediator.

Every time each class needs to interact with an object, it calls a method from the mediator and only the mediator knows what object needs to be called.

For the mediator we just need an interface. It is a good practice to use interface or an abstract class for the mediator. In this way you are able to have different implementation of the mediator object.


Greek public services are a mess. Each time a Greek citizen needs to use a public service, he faces a huge bureaucracy. So, a citizen has to transfer and get a bunch of documents from one public service to the other. In this case the Greek citizen is the mediator. He is the one who has to go and find the right document in a group of public services. This is wrong from many aspects but it is a reality.

Let’s start our example by implementing this situation but a little differently, in the right way. Instead of using citizen as a intermediary mean we will create a mediator which is going to be aware of all public services and how to use them. So, the citizen can go and ask the mediator for something and it is going to interact with public services (objects) for the desirable result.

In the following example a Greek citizen who wants to start a new company is represented.

We start with an interface for mediator.

Let’s implement this mediator.

Now it’s time to implement the objects which are going to interact with mediator.

The following code is representing the Greek citizen.

Let’s create a function wich runs the code


You can download the source code from GitHub.

1 Comment

  1. geodoo June 19, 2017 at 12:23 pm

    Haha, I love the political insinuation! Greek public services rock!!

Comments are closed.