This is the third video of the section mediator design pattern.
Previously we learned about the state design pattern in this video.
We are going to develop an extremely simple arithmetic calculator.
You're probably thinking that a calculator is so simple that it does not need any pattern but we will
see that this is not exactly true.
Our calculator will only do two very simple operations sum and subtract let us continue with mediator
pattern as its name implies it is a pattern that will be in between two types to exchange information.
But why will we want this behavior at all.
Let's look at this in detail.
One of the key objectives of any design pattern is to avoid tight coupling between objects.
This can be done in many ways as we have seen already but one particularly effective method when the
application grows a lot is the mediator pattern the mediator pattern is the perfect example of a pattern
that is commonly used by every programmer without thinking very much about it.
Mediate a pattern will act the type in charge of exchanging communication between two objects.
This way the communicating objects don't need to know each other and can change more freely.
The pattern that maintains which objects give what information is the mediator as previously described.
The main objective of the mediator pattern is about loose coupling and encapsulation.
The objectives are listed here.
First of all to provide loose coupling between two objects that must communicate between them and next
to reduce the amount of dependencies of a particular type to the minimum bypassing these needs to the
mediator pattern.
It sounds quite funny to talk about acceptance criteria to define a calculator but let's do it anyway.
We need to define an operation called Sum that takes a number and adds it to another number.
Secondly we define an operation called subtract that takes a number and subtract it to another number.
Well I don't know about you but I really need a rest after this complex criteria.
So why are we defining this so much patience.
You will have your answer soon we will have to jump directly to the implementation because we cannot
test that the sum will be correct.
Well we can but we will be testing if Goh is correctly written we could test that we pass the acceptance
criteria but it's a bit of an overkill for our example.
So let's start by implementing the necessary types.
Now open the mediator dot go file which I've already created.
And here we add the package name and types.
Well this looks quite awkward.
We already have numeric types and go to perform these operations.
We don't need a type for each number.
But let let's continue for a second with this insane approach.
Let's implement the 1 struct
so here it is.
Okay I'll stop here.
What is wrong with this implementation.
This is completely crazy.
It's overkill to make every operation possible between numbers to make sums especially when we have
more than one digit.
Well believe it or not this is how a lot of software is commonly designed today.
A small app where an object uses two or three objects grows and it ends up using dozens of them.
It becomes an absolute hell to simply add or remove or type from the application because it is hidden
in some of this craziness.
So what can we do in this calculator.
Use a mediator type that frees all the cases.
Let's add the function sum we have just developed a couple of numbers to keep things short.
The sum function acts as a mediator between two numbers.
First it checks the type of the first number named a then for each type of the first number.
It checks the type of the second number named B and returns the resulting type.
While the solution still looks very crazy now the only one that knows all about possible numbers in
the calculator is the sum function.
But take a closer look and you'll see that we have added a type of case for the end type.
We have cases 1 2 and end inside the end case.
We also have another int case for the B number.
What do we do here.
If both types are of the case we can return the sum of them.
Do you think that this will work.
Let's write a simple main function.
Okay here we print the sum of type 1 and Type 2 by using the percent hash v format we ask to print information
about the type.
The second line in the function uses int types and we also print the result.
Let's see what is the output produced in the console.
Save the file and move to the terminal type the command go run mediator.
Whoops we forgot to import F.M. T.
Let's go back to the file and do it
let's save the file and run it again.
So here's the output.
Not very impressive right.
But let's think for a second by using the mediator pattern we have been able to refactor the initial
calculator where we have to define every operation on every type to a mediator pattern the sum function.
The nice thing is that thanks to the mediator pattern we have been able to start using integers as values
for our calculator.
We have just defined the simplest example by adding two integers but we could have done the same with
an integer and the type let us make some changes to our mediator right over here.
In case we need to make some changes done with this small modification we can now use Type 1 with an
int as number B if we keep working on this mediator pattern we could achieve a lot of flexibility between
types without having to implement every possible operation between them generating a tight coupling
will add a new some method in the main method to see this in action.
Let's go to the main function and make the changes save the file move to the terminal and run it again.
Nice the mediator pattern is in charge of knowing about the possible types and returns the most convenient
type for our case which is an integer.
Now we could keep growing the sum function until we completely get rid of using the numeric types we
have defined.
So we have carried out a disruptive example to try and think outside the box and reason deeply about
the mediator pattern tight coupling between entities and an app can become really complex to deal with
in the future and allow more difficult refactoring if needed.
Just remember that the mediator pattern is there to act as a Managing Type between two types that don't
know about each other so that you can take one of the types without affecting the other and replace
a type in a more easy and convenient way.
Awesome in this video we have explored about the mediator design pattern in the next video.
We will look into the observer design pattern.