WEBVTT 00:00.300 --> 00:04.740 This is the third video of the section mediator design pattern. 00:04.740 --> 00:09.000 Previously we learned about the state design pattern in this video. 00:09.030 --> 00:13.200 We are going to develop an extremely simple arithmetic calculator. 00:13.200 --> 00:18.840 You're probably thinking that a calculator is so simple that it does not need any pattern but we will 00:18.840 --> 00:21.490 see that this is not exactly true. 00:21.510 --> 00:29.070 Our calculator will only do two very simple operations sum and subtract let us continue with mediator 00:29.080 --> 00:35.740 pattern as its name implies it is a pattern that will be in between two types to exchange information. 00:35.740 --> 00:38.920 But why will we want this behavior at all. 00:38.920 --> 00:40.650 Let's look at this in detail. 00:40.930 --> 00:46.060 One of the key objectives of any design pattern is to avoid tight coupling between objects. 00:46.060 --> 00:51.820 This can be done in many ways as we have seen already but one particularly effective method when the 00:51.820 --> 00:57.910 application grows a lot is the mediator pattern the mediator pattern is the perfect example of a pattern 00:57.910 --> 01:02.860 that is commonly used by every programmer without thinking very much about it. 01:02.990 --> 01:09.070 Mediate a pattern will act the type in charge of exchanging communication between two objects. 01:09.070 --> 01:14.340 This way the communicating objects don't need to know each other and can change more freely. 01:14.500 --> 01:21.130 The pattern that maintains which objects give what information is the mediator as previously described. 01:21.130 --> 01:26.450 The main objective of the mediator pattern is about loose coupling and encapsulation. 01:26.530 --> 01:28.290 The objectives are listed here. 01:28.630 --> 01:34.420 First of all to provide loose coupling between two objects that must communicate between them and next 01:34.690 --> 01:40.360 to reduce the amount of dependencies of a particular type to the minimum bypassing these needs to the 01:40.360 --> 01:41.990 mediator pattern. 01:42.010 --> 01:48.340 It sounds quite funny to talk about acceptance criteria to define a calculator but let's do it anyway. 01:48.430 --> 01:53.890 We need to define an operation called Sum that takes a number and adds it to another number. 01:53.890 --> 02:01.160 Secondly we define an operation called subtract that takes a number and subtract it to another number. 02:01.220 --> 02:05.090 Well I don't know about you but I really need a rest after this complex criteria. 02:05.150 --> 02:08.790 So why are we defining this so much patience. 02:08.870 --> 02:14.240 You will have your answer soon we will have to jump directly to the implementation because we cannot 02:14.240 --> 02:16.510 test that the sum will be correct. 02:16.520 --> 02:23.150 Well we can but we will be testing if Goh is correctly written we could test that we pass the acceptance 02:23.150 --> 02:27.200 criteria but it's a bit of an overkill for our example. 02:27.200 --> 02:30.710 So let's start by implementing the necessary types. 02:30.710 --> 02:34.510 Now open the mediator dot go file which I've already created. 02:34.610 --> 02:38.110 And here we add the package name and types. 02:38.150 --> 02:40.890 Well this looks quite awkward. 02:40.910 --> 02:45.030 We already have numeric types and go to perform these operations. 02:45.110 --> 02:47.550 We don't need a type for each number. 02:47.550 --> 02:51.730 But let let's continue for a second with this insane approach. 02:52.150 --> 02:54.170 Let's implement the 1 struct 02:57.800 --> 02:59.090 so here it is. 02:59.860 --> 03:01.720 Okay I'll stop here. 03:01.720 --> 03:04.020 What is wrong with this implementation. 03:04.030 --> 03:05.620 This is completely crazy. 03:05.630 --> 03:11.350 It's overkill to make every operation possible between numbers to make sums especially when we have 03:11.350 --> 03:13.150 more than one digit. 03:13.150 --> 03:18.070 Well believe it or not this is how a lot of software is commonly designed today. 03:18.130 --> 03:24.730 A small app where an object uses two or three objects grows and it ends up using dozens of them. 03:24.730 --> 03:30.730 It becomes an absolute hell to simply add or remove or type from the application because it is hidden 03:30.730 --> 03:32.860 in some of this craziness. 03:32.860 --> 03:35.710 So what can we do in this calculator. 03:35.830 --> 03:39.980 Use a mediator type that frees all the cases. 03:40.150 --> 03:45.760 Let's add the function sum we have just developed a couple of numbers to keep things short. 03:45.790 --> 03:49.300 The sum function acts as a mediator between two numbers. 03:49.300 --> 03:55.220 First it checks the type of the first number named a then for each type of the first number. 03:55.240 --> 04:00.180 It checks the type of the second number named B and returns the resulting type. 04:00.370 --> 04:06.130 While the solution still looks very crazy now the only one that knows all about possible numbers in 04:06.130 --> 04:08.950 the calculator is the sum function. 04:09.070 --> 04:14.380 But take a closer look and you'll see that we have added a type of case for the end type. 04:14.440 --> 04:19.320 We have cases 1 2 and end inside the end case. 04:19.330 --> 04:22.840 We also have another int case for the B number. 04:23.020 --> 04:24.210 What do we do here. 04:24.250 --> 04:29.110 If both types are of the case we can return the sum of them. 04:29.170 --> 04:31.390 Do you think that this will work. 04:31.390 --> 04:33.810 Let's write a simple main function. 04:34.000 --> 04:42.880 Okay here we print the sum of type 1 and Type 2 by using the percent hash v format we ask to print information 04:42.880 --> 04:44.180 about the type. 04:44.230 --> 04:49.430 The second line in the function uses int types and we also print the result. 04:49.570 --> 04:53.260 Let's see what is the output produced in the console. 04:53.260 --> 04:59.590 Save the file and move to the terminal type the command go run mediator. 04:59.590 --> 05:02.540 Whoops we forgot to import F.M. T. 05:02.630 --> 05:04.500 Let's go back to the file and do it 05:08.410 --> 05:11.140 let's save the file and run it again. 05:11.140 --> 05:12.970 So here's the output. 05:13.090 --> 05:15.150 Not very impressive right. 05:15.370 --> 05:21.160 But let's think for a second by using the mediator pattern we have been able to refactor the initial 05:21.160 --> 05:28.480 calculator where we have to define every operation on every type to a mediator pattern the sum function. 05:28.480 --> 05:33.880 The nice thing is that thanks to the mediator pattern we have been able to start using integers as values 05:33.880 --> 05:35.830 for our calculator. 05:35.830 --> 05:41.080 We have just defined the simplest example by adding two integers but we could have done the same with 05:41.080 --> 05:47.070 an integer and the type let us make some changes to our mediator right over here. 05:47.140 --> 05:55.810 In case we need to make some changes done with this small modification we can now use Type 1 with an 05:55.900 --> 06:02.290 int as number B if we keep working on this mediator pattern we could achieve a lot of flexibility between 06:02.290 --> 06:08.110 types without having to implement every possible operation between them generating a tight coupling 06:08.930 --> 06:12.920 will add a new some method in the main method to see this in action. 06:13.000 --> 06:20.360 Let's go to the main function and make the changes save the file move to the terminal and run it again. 06:20.650 --> 06:26.530 Nice the mediator pattern is in charge of knowing about the possible types and returns the most convenient 06:26.530 --> 06:29.530 type for our case which is an integer. 06:29.530 --> 06:34.750 Now we could keep growing the sum function until we completely get rid of using the numeric types we 06:34.750 --> 06:36.040 have defined. 06:36.040 --> 06:42.100 So we have carried out a disruptive example to try and think outside the box and reason deeply about 06:42.100 --> 06:47.740 the mediator pattern tight coupling between entities and an app can become really complex to deal with 06:47.740 --> 06:52.110 in the future and allow more difficult refactoring if needed. 06:52.120 --> 06:58.090 Just remember that the mediator pattern is there to act as a Managing Type between two types that don't 06:58.090 --> 07:03.340 know about each other so that you can take one of the types without affecting the other and replace 07:03.340 --> 07:06.560 a type in a more easy and convenient way. 07:06.790 --> 07:12.580 Awesome in this video we have explored about the mediator design pattern in the next video. 07:12.640 --> 07:15.220 We will look into the observer design pattern.