WEBVTT 00:00.330 --> 00:05.420 Hey we are now the last video of this section prototype design pattern. 00:05.430 --> 00:08.520 Previously we looked at Abstract Factory. 00:08.520 --> 00:13.770 In this video we will build a small component of an imaginary customized shirt shop that will have a 00:13.770 --> 00:17.070 few shirts with their default colors and prices. 00:17.070 --> 00:23.910 Each shirt will also have a stock keeping unit to identify items stored at a specific location. 00:23.910 --> 00:30.650 The prototype pattern we will use an already created instance of some type to clone it and complete 00:30.650 --> 00:33.820 it with the particular needs of each context. 00:33.870 --> 00:39.150 The aim of the prototype pattern is to have an object or a set of objects that is already created at 00:39.150 --> 00:44.780 compilation time but which you can clone as many times as you want at runtime. 00:44.790 --> 00:50.610 This is useful for example as a default template for a user who has just registered with your web page 00:50.850 --> 00:53.880 or a default pricing plan in some service. 00:53.880 --> 00:59.130 The key difference between this and a builder pattern is that objects are cloned for the user. 00:59.130 --> 01:05.970 Instead of building them at runtime You can also build a cache like solution storing information using 01:05.970 --> 01:07.380 a prototype. 01:07.380 --> 01:13.150 The main objective for the prototype design pattern is to avoid repetitive object creation. 01:13.200 --> 01:18.270 Imagine a default object composed of dozens of fields and embedded types. 01:18.390 --> 01:21.030 We don't want to write everything needed by this type. 01:21.060 --> 01:27.000 Every time that we use the object especially if we can mess it up by creating instances with different 01:27.000 --> 01:28.140 foundations. 01:28.290 --> 01:35.130 So we need to maintain a set of objects that will be cloned to create new instances and provide a default 01:35.130 --> 01:38.570 value of some type to start working on top of it. 01:38.580 --> 01:45.460 And lastly free CPSU of complex object initialization to take more memory resources. 01:45.570 --> 01:51.120 We will build a small component of an imaginary customised shirts shop that will have a few shirts with 01:51.120 --> 01:53.260 their default colours and prices. 01:53.340 --> 02:00.570 Each shirt will also have a stock keeping unit that is S.K. EU which is a system to identify items stored 02:00.570 --> 02:06.720 at a specific location that will need an update to achieve what is described in the example we will 02:06.720 --> 02:09.060 use a prototype of shirts. 02:09.060 --> 02:14.250 Each time we need a new shirt we will take this prototype clone it and work with it. 02:14.250 --> 02:19.370 In particular those are the acceptance criteria for using the prototype pattern design method. 02:19.380 --> 02:26.280 In this example to have a shirt clone or object and interface to ask for different types of shirts white 02:26.430 --> 02:33.890 black and blue at fifteen point zero sixteen point zero and seventeen point zero dollars respectively. 02:33.960 --> 02:39.540 When you're asked for a white shirt a clone of the white shirt must be made and the new instance must 02:39.540 --> 02:41.730 be different from the original one. 02:41.820 --> 02:48.540 The SCA you've created object shouldn't affect a new object creation an info method must give me all 02:48.540 --> 02:53.910 the information available on the instance fields including the updated SDK you. 02:54.030 --> 02:57.000 Now let's start with unit test. 02:57.000 --> 03:01.590 First we will need a shirt clone or interface and an object that implements it. 03:01.620 --> 03:07.850 Also we need a package level function called get shirts closer to retrieve a new instance of the clone. 03:08.310 --> 03:14.850 So I have created a folder named prototype within the creation or folder and here I have created two 03:14.850 --> 03:22.890 files and named them as prototype dot go and prototype underscored test dot GO LET'S OPEN THE PROTOTYPE 03:22.890 --> 03:24.160 dot go file. 03:24.240 --> 03:27.730 Here we are the creation or package and import errors. 03:27.750 --> 03:32.150 Now we add shirt cleaner interface and shirt cache structure. 03:32.220 --> 03:37.950 Now we need an object struct to clone which implements an interface to retrieve the information of its 03:38.040 --> 03:39.230 own fields. 03:39.270 --> 03:44.180 We will call the object shirt and the item info getter interface. 03:44.280 --> 03:47.840 So here's the code which you need to add to this file. 03:47.910 --> 03:54.510 Now have you realized that the type code shirt color that we defined is just a byte type. 03:54.630 --> 03:58.940 Maybe you are wondering why we haven't simply used the byte type. 03:59.010 --> 04:05.100 We could but this way we created an easily readable struct which we can upgrade with some methods in 04:05.100 --> 04:06.660 the future if required. 04:06.660 --> 04:12.540 For example we could write a string method that returns the color in the string format that is white 04:12.540 --> 04:17.820 for type 1 black for type 2 and blue for Type 3. 04:17.820 --> 04:24.600 Now let's save this file and move the prototype test dot go and let's write our first test. 04:24.600 --> 04:30.690 Here we first import testing and here's the code which we'll be using for our first tests. 04:30.690 --> 04:35.850 We will cover the first case of our scenario where we need a clone or object that we can use to ask 04:35.850 --> 04:39.080 for different shirt colors for the second case. 04:39.180 --> 04:44.430 We will take the original object which we can access because we are in the scope of the package and 04:44.580 --> 04:47.920 we will compare it with our t shirt one instance. 04:48.050 --> 04:51.050 Let's do it now for the third case. 04:51.090 --> 04:57.160 First we will type assert item 1 to a shirt so we can set an SCA you. 04:57.260 --> 04:59.150 We will create a second shirt. 04:59.450 --> 05:05.390 Also white and we will type asserted to to check that the SCA use are different. 05:05.390 --> 05:08.060 Let me add the lines of code for this. 05:08.090 --> 05:13.100 Finally for the fourth case we log the invoke the First and Second shirts. 05:13.190 --> 05:16.510 So we do this with T dot log F.. 05:16.880 --> 05:20.360 Let's add the line of code to print the memory positions of both shirts. 05:20.540 --> 05:23.820 So we make this assertion at a more physical level. 05:24.020 --> 05:27.610 Now save the file and move on to the terminal. 05:27.620 --> 05:32.190 Finally we run the tests so that we can check to see if it fails. 05:32.300 --> 05:35.150 We have to stop there so that the tests don't panic. 05:35.150 --> 05:40.430 If we tried to use a nil object that is returned by the get shirts closure function. 05:40.580 --> 05:46.400 Now we step ahead for implementation open the prototype dot go file. 05:46.400 --> 05:48.930 We will start with the Get clone method. 05:48.950 --> 05:53.960 This method should return an item of the specified type and we have three types. 05:54.140 --> 05:56.930 White black and blue. 05:56.930 --> 06:03.890 So now that we have the three prototypes to work over we can implement get clone s and method. 06:03.890 --> 06:09.800 The shirt structure which you see highlighted also needs a Get Info implementation to print the contents 06:09.800 --> 06:11.170 of the instances. 06:11.210 --> 06:13.900 Now move back to the terminal. 06:14.030 --> 06:18.190 Finally let's run the tests to see that everything is now working. 06:18.230 --> 06:22.220 Remember to set the hyphen v flag when running the tests in the log. 06:22.220 --> 06:27.050 You can check that shirt 1 and shirt to have different SDK use. 06:27.050 --> 06:30.860 Also we can see the memory positions of both objects. 06:31.010 --> 06:36.020 Take into account that the position shown on your computer will probably be different. 06:36.020 --> 06:36.830 Cool. 06:36.830 --> 06:38.030 That's all for this video. 06:39.620 --> 06:45.710 Let us summarize what we learned about the prototype design pattern the prototype pattern is a powerful 06:45.710 --> 06:49.010 tool to build caches and default objects. 06:49.030 --> 06:54.050 You have probably realized too that some patterns can overlap a bit but they have small differences 06:54.050 --> 07:00.940 that make them more appropriate in some cases and not so much in others in this section. 07:01.000 --> 07:06.550 We have seen five main creation or design patterns commonly used in the software industry. 07:06.550 --> 07:12.550 The purpose is to abstract the user from the creation of objects the complexity or maintain ability 07:12.550 --> 07:13.630 purposes. 07:13.720 --> 07:19.690 They have been the foundation of thousands of applications and libraries since the 1990s and most of 07:19.690 --> 07:24.690 the software we use today has many of these creation or patterns under the hood. 07:24.730 --> 07:31.180 It's worth mentioning that these patterns on not thread free in more advanced sanctions which we will 07:31.180 --> 07:33.150 include in the third part of this course. 07:33.280 --> 07:38.560 We will see concurrent programming and go and how to create some of the more critical design patterns 07:38.770 --> 07:42.620 using a concurrent approach in the next section. 07:42.700 --> 07:45.490 We will explore about structural patterns.