WEBVTT 00:00.420 --> 00:06.630 We are now at the third video of the section command design pattern in the previous video. 00:06.660 --> 00:11.080 We looked at the chain of responsibility design pattern in this video. 00:11.130 --> 00:17.460 We will see how to create a simple Q by implementing the command design pattern to finish with this 00:17.460 --> 00:18.240 section. 00:18.330 --> 00:24.360 We will see also the command pattern a tiny design pattern but still frequently used. 00:24.390 --> 00:25.620 You need a way to connect. 00:25.620 --> 00:30.030 Types that are really unrelated so design a command for them. 00:30.150 --> 00:35.280 The command design pattern is quite similar to the strategy design pattern but with key differences 00:35.670 --> 00:41.790 while in the strategy pattern we focus on changing algorithms in the Command pattern we focus on the 00:41.850 --> 00:49.230 invocation of something or on the abstraction of some type a command pattern is commonly seen as a container 00:49.620 --> 00:55.800 you put something like the info for user interaction on a UI that could be a click on log in and pass 00:55.800 --> 00:57.020 it as a command. 00:57.120 --> 01:02.250 You don't need to have the complexity related to the click on log in action in the command but simply 01:02.340 --> 01:03.940 the action itself. 01:03.960 --> 01:08.610 An example for the organic world would be a box for a delivery company. 01:08.610 --> 01:14.490 We can put anything on it but as a delivery company we are interested in managing the box instead of 01:14.490 --> 01:16.500 its contents directly. 01:16.500 --> 01:21.930 The Command pattern will be used heavily when dealing with channels with channels you can send any message 01:21.930 --> 01:22.710 through it. 01:22.710 --> 01:28.410 But if we need a response from the receiving side of the channel a common approach is to create a command 01:28.470 --> 01:32.370 that has a second response channel attached to where we are listening. 01:33.060 --> 01:39.150 Similarly a good example would be a multiplayer video game where every stroke of each user can be sent 01:39.150 --> 01:42.390 as commands to the rest of the users through the network. 01:42.780 --> 01:49.200 When using the command design pattern we are trying to encapsulate some sort of action or information 01:49.200 --> 01:52.920 in a light package that must be processed somewhere else. 01:52.920 --> 01:58.830 It's similar to the strategy pattern but in fact a command could trigger a pre configured strategy somewhere 01:58.830 --> 01:59.250 else. 01:59.340 --> 02:01.280 So they are not the same. 02:01.290 --> 02:08.070 Here are the objectives for this design pattern to put some information into a box just the receiver 02:08.070 --> 02:11.060 will open the box and know its contents. 02:11.070 --> 02:15.240 Secondly to delegate some action somewhere else. 02:15.240 --> 02:19.160 The behavior is also explained in the diagram on your screen. 02:19.200 --> 02:22.560 There we have a command interface with a get interface method. 02:22.560 --> 02:25.440 We have a type A and Type B. 02:25.470 --> 02:32.100 The idea is that A and B implement the command interface to return themselves as an interface. 02:32.100 --> 02:34.110 As now they implement the command. 02:34.110 --> 02:39.650 They can be used in a command handler which doesn't care very much about the underlying type. 02:39.720 --> 02:46.560 Now a and b can travel through functions that handle commands or store commands freely but to be handler 02:46.560 --> 02:53.880 can take an object from any command handler to unwrap it and take its B content as well as a command 02:53.880 --> 02:56.640 handler with its a content. 02:56.640 --> 03:01.980 We put the information in a box that is the command and delegate what to do with it to the handlers 03:02.070 --> 03:03.950 of commands. 03:03.970 --> 03:08.130 Now let's first understand the example which will be working with on this video. 03:08.620 --> 03:10.850 So it's a simple cue. 03:10.900 --> 03:13.630 Our first example is going to be pretty small. 03:13.660 --> 03:18.520 We will put some information into a command implementer and we will have a cue. 03:18.580 --> 03:24.460 We will create many instances of a type implementing a command pattern and we will pass them to a queue 03:24.460 --> 03:30.660 that will store the commands until three of them are on the queue at which time it will process them. 03:30.700 --> 03:36.940 So the ideal acceptance criteria to understand well the implications of the command should reflect somehow 03:36.940 --> 03:43.320 the creation of a box that can accept unrelated types and the execution of the command itself. 03:43.330 --> 03:46.610 We need a constructor of console printing commands. 03:46.750 --> 03:51.150 When using this constructor with a string it will return a command that will print it. 03:51.190 --> 03:58.480 In this case the handler is inside the command that acts as a box and as a handler we need a data structure 03:58.480 --> 04:01.980 that stores incoming commands in a queue and prints them. 04:02.050 --> 04:05.260 Once the queue reaches the length of 3. 04:05.440 --> 04:07.950 Now let's move on to the implementation. 04:07.960 --> 04:11.930 This pattern is quite simple and we will write a few different examples. 04:11.980 --> 04:16.170 So we'll implement the library directly to keep things light and short. 04:16.420 --> 04:22.570 The classical command design pattern usually has a common type structure with an execute method. 04:22.570 --> 04:26.750 We are also going to use this structure as it is quite flexible and simple. 04:26.790 --> 04:28.410 I have created a folder with the name. 04:28.450 --> 04:29.510 Example 1. 04:29.590 --> 04:31.540 And here I created a file command. 04:31.540 --> 04:36.270 Dot go let's open the file and add the package name important. 04:36.270 --> 04:39.090 F empty and the interface. 04:39.190 --> 04:42.310 This is generic enough to fill a lot of unrelated types. 04:42.370 --> 04:42.970 Think about it. 04:43.140 --> 04:48.310 We are going to create a type that prints to console when using the execute method but it could print 04:48.310 --> 04:50.920 a number or launch a rocket as well. 04:50.920 --> 04:58.070 The key here is to focus on invocations because the handlers are also in command so we need some type. 04:58.090 --> 05:00.910 Implementing this interface and printing to the console. 05:00.970 --> 05:02.980 Some sort of message. 05:03.020 --> 05:05.410 Now let's add the next part of the code. 05:05.630 --> 05:10.200 The console output type implements the command interface and prints to the console. 05:10.210 --> 05:15.130 The member called message as defined in the first acceptance criterion. 05:15.170 --> 05:20.480 We need a command constructor that accepts a message string and returns the commanded face. 05:20.690 --> 05:25.160 It will have the signature function create command as String command. 05:25.760 --> 05:28.140 So that's what we need to add next. 05:28.190 --> 05:29.310 Let me do it. 05:30.030 --> 05:38.610 Call the command Q will define a very simple type called Command Q to store in a Q any type for implementing 05:38.610 --> 05:39.600 the command interface. 05:40.650 --> 05:41.650 Here we are the type. 05:41.650 --> 05:48.450 Command Q done the command Q types those an array of the commands interface. 05:48.450 --> 05:55.050 When the Q array reaches three items it executes all the commands stored in the Q field if it hasn't 05:55.050 --> 05:59.070 reached the required length yet it just stalls the command. 05:59.100 --> 06:06.000 Now we will create five commands enough to trigger the command Q mechanism and add them to the Q Each 06:06.000 --> 06:07.560 time a command is created. 06:07.650 --> 06:11.730 The message creating command will be printed to the console. 06:11.940 --> 06:17.670 When we create the third command the automatic command executor will be launched printing the first 06:17.670 --> 06:23.750 three messages we create and that two commands more because we haven't reached the third command again. 06:23.820 --> 06:28.530 They won't be printed and just creating command messages will be printed. 06:28.650 --> 06:33.690 So here's the function main with the five commands which I just spoke about. 06:33.690 --> 06:37.130 Now let's save this file and run the main program. 06:37.470 --> 06:43.950 Our definition said that the commands are processed once every three messages and we will create a total 06:43.950 --> 06:45.540 of five messages. 06:45.540 --> 06:51.960 The first three messages must be printed but not the fourth and fifth because we didn't reach a sixth 06:51.960 --> 06:54.810 message to trigger the command processing. 06:54.810 --> 06:57.200 It's time to see whether this happens or not. 06:57.330 --> 07:02.140 Run the command go run command dot go enter. 07:02.670 --> 07:08.610 As you can see the fourth and fifth messages aren't printed as expected but we know that the commands 07:08.610 --> 07:11.550 were created and stored on the array. 07:11.550 --> 07:17.280 They just weren't processed because the key was waiting for one command more to trigger the processor. 07:17.280 --> 07:19.560 Now let's talk more examples. 07:19.560 --> 07:25.590 The previous example shows how to use a command handler to execute the contents of the command but a 07:25.590 --> 07:31.530 common way to use a command pattern is to delegate the information instead of the execution to a different 07:31.620 --> 07:32.560 object. 07:32.760 --> 07:39.030 For example instead of printing to the console we will create a command that extract information open 07:39.030 --> 07:46.980 the file command don't go here we first add the package and import f empty and time and add command 07:46.980 --> 07:48.270 interface. 07:48.270 --> 07:53.790 In this case our command interface will have a method named info that will retrieve some information 07:53.790 --> 07:55.260 from its implementer. 07:55.350 --> 07:57.480 We will create two implementations. 07:57.600 --> 08:03.390 One will return the time passed since the creation of the command to its execution. 08:03.390 --> 08:04.950 Let's do it right now. 08:05.130 --> 08:11.170 The time dot since function returns the time elapsed since the time stored in the previous parameter. 08:11.280 --> 08:17.460 We return the string representation of the past time by calling the string method on the time dot time 08:17.490 --> 08:18.590 type. 08:18.750 --> 08:24.960 The second implementation of our new command will return the message Hello world which we are about 08:24.960 --> 08:26.780 to add to the next. 08:26.790 --> 08:31.560 And here it is our main function will simply create an instance of each type. 08:31.710 --> 08:37.350 Then waits for a second and then prints the info returned from each command. 08:37.350 --> 08:43.440 Now let's add the main function here the time dot sleep function stops the execution of the current 08:43.440 --> 08:47.100 go routine for the specified period a second. 08:47.100 --> 08:53.550 So to recall the time command variables stores the time when the program was started and its info method 08:53.550 --> 08:59.940 returns a string representation of the time that passed since we gave a value to the type to the moment 08:59.940 --> 09:02.820 where we called the info method on it. 09:02.820 --> 09:06.270 The helo command variable returns the message Hello world. 09:06.270 --> 09:12.360 When we call it info method here we haven't implemented a command handler again to keep things simple 09:12.480 --> 09:18.420 but we can consider the console as the handler because we can only print ASCII characters on it like 09:18.420 --> 09:25.590 the ones retrieved by the info method now save the file and move on to the terminal let's run the main 09:25.590 --> 09:33.680 function go run command dot go here we are in this case we retrieve some information by using the command 09:33.710 --> 09:40.070 pattern one type stores time information while the other stores nothing and it simply returns the same 09:40.070 --> 09:46.760 simple string each time we run the main function will return a different elapsed time so don't worry 09:46.760 --> 09:52.830 if the time doesn't match with the one in the example do you remember the chain of responsibility design 09:52.830 --> 09:59.370 pattern we were passing a string message between links to print its contents but we could be using the 09:59.370 --> 10:05.640 previous command to retrieve information for logging to the console will mainly reuse the code that 10:05.640 --> 10:11.410 we have written already the command interface will be from the type interface that returns a string 10:11.530 --> 10:18.790 from the previous example I have created a file with the name chain underscore command dot go let's 10:18.790 --> 10:25.540 open it and add the lines of code we need to first declare the package Main and import half empty and 10:25.540 --> 10:26.860 time. 10:26.860 --> 10:29.740 Next we declare the command interface. 10:29.740 --> 10:33.000 Now let's use the command implementation of the time passed. 10:33.000 --> 10:34.610 Type 2. 10:34.630 --> 10:35.820 Okay. 10:35.890 --> 10:42.600 Remember that this type returns the elapsed time from the object creation on its info string method. 10:42.610 --> 10:48.400 We also need the chain logger interface from the chain of responsibility design pattern we used earlier 10:48.400 --> 10:54.340 in this section but this time it will pass commands on its next to method instead of string. 10:55.000 --> 10:58.390 So now we add the chain logger interface. 10:58.390 --> 11:02.920 Now we'll use the same type for two links in the chain for simplicity. 11:02.920 --> 11:08.830 This link is very similar to the first logger type from the chain of responsibility example but this 11:08.830 --> 11:16.030 time it will append the message elapsed time from creation and it will wait one second before printing 11:16.420 --> 11:19.960 we'll call it logger instead of first logger. 11:19.960 --> 11:21.640 Let's add the code for it. 11:21.880 --> 11:22.900 Fine. 11:22.900 --> 11:27.710 Finally we need a main function to execute the chain that takes command pointers. 11:27.730 --> 11:31.060 Let's add it to line by line. 11:31.120 --> 11:35.170 We create a variable called second with a pointer to a logger. 11:35.170 --> 11:38.380 This is going to be the second link in our chain. 11:38.380 --> 11:43.210 Then we create a variable called first that will be the first link in the chain. 11:43.330 --> 11:45.890 The first link points to the second variable. 11:45.940 --> 11:47.890 The second link in the chain. 11:47.980 --> 11:52.710 Then we create an instance of time passed to use it as the command type. 11:53.200 --> 11:57.370 The start time of this command is the execution time the time dot. 11:57.370 --> 12:01.810 Now method returns the time in the moment of the execution. 12:01.810 --> 12:05.760 Finally we pass the command interface to the chain on the first dot. 12:05.770 --> 12:08.050 Next command statement. 12:08.050 --> 12:10.860 We are now ready to see the output of this program. 12:10.930 --> 12:17.550 Let us move to the terminal run the command go run chain command dot go. 12:17.770 --> 12:20.510 The resulting output is reflected in the diagram. 12:20.620 --> 12:26.440 The command with the time field is pushed to the first link that knows how to execute commands of any 12:26.440 --> 12:27.350 type. 12:27.430 --> 12:33.460 Then it passes the command to the second link that also knows how to execute commands. 12:33.460 --> 12:39.540 This approach hides the complexity behind each command execution from the command handlers on each link. 12:39.640 --> 12:45.610 The functionality hidden behind the command can be simple or incredibly complex but the idea here is 12:45.610 --> 12:50.890 to reuse the handler to manage many types of unrelated implementations. 12:50.900 --> 12:57.350 Now let's round up whatever we have learned about the command pattern so command is a very tiny design 12:57.350 --> 12:58.190 pattern. 12:58.190 --> 13:03.260 Its functionality is quite easy to understand but it's widely used for its simplicity. 13:03.260 --> 13:09.500 It looks very similar to the strategy pattern but remember that strategy is about having many algorithms 13:09.650 --> 13:15.620 to achieve some specific task but all of them achieve the same task in the Command pattern. 13:15.620 --> 13:20.510 You can have many tasks to execute and not all of them need to be equal. 13:20.630 --> 13:27.380 So in short the Command pattern is about execution encapsulation and delegation so that just the receiver 13:27.560 --> 13:30.560 or receivers trigger that execution. 13:30.560 --> 13:35.120 In this section we have taken our first steps in the behavioral patterns. 13:35.120 --> 13:40.910 The objective of the section was to introduce you to the concept of algorithm and execution encapsulation 13:41.120 --> 13:48.110 using proper interfaces and structures with the strategy we have encapsulated algorithms with the chain 13:48.110 --> 13:54.200 of responsibility handlers and with the command design pattern executions the chain of responsibility 13:54.200 --> 14:00.200 pattern opens the door of middleware of any type and plug in like libraries to improve the functionality 14:00.200 --> 14:01.890 of some part. 14:01.910 --> 14:07.910 Finally the Command pattern is the most common pattern for UI handling but also very useful in many 14:07.910 --> 14:13.670 other scenarios where we need some type of handling between many unrelated types that are travelling 14:13.670 --> 14:16.380 through the code in the next section. 14:16.450 --> 14:20.860 We will look into template momento and interpreter design patterns.