WEBVTT 00:00.360 --> 00:02.750 This is the second video of this section. 00:02.940 --> 00:09.840 Build a design pattern where we'll be reusing an algorithm to create many implementations of an interface. 00:09.840 --> 00:14.480 In the previous video we looked at Singleton pattern in this video. 00:14.550 --> 00:21.090 We'll take an example of vehicle manufacturing and see the implementation talking about creation or 00:21.090 --> 00:22.290 design patterns. 00:22.290 --> 00:28.980 It looks pretty semantic to have a builder design pattern the builder pattern helps us construct complex 00:29.100 --> 00:35.180 objects without directly instantiating their struct or writing the logic they require. 00:35.190 --> 00:40.710 Imagine an object that could have dozens of fields that are more complex struct themselves. 00:40.710 --> 00:46.580 Now imagine that you have many objects with these characteristics and you could have more. 00:46.620 --> 00:51.810 We don't want to write the logic to create all these objects in the package that just needs to use the 00:51.810 --> 00:52.840 objects. 00:53.190 --> 00:59.310 Instance creation can be as simple as providing the opening and closing braces and leaving the instance 00:59.340 --> 01:07.290 with zero values or as complex as an object that needs to make some API calls check states and create 01:07.410 --> 01:09.550 objects or its fields. 01:09.570 --> 01:14.850 You could also have an object that is composed of many objects something that's really idiomatic and 01:14.850 --> 01:18.210 go as it doesn't support inheritance. 01:18.210 --> 01:23.680 At the same time you could be using the same technique to create many types of objects. 01:23.730 --> 01:29.270 For example you'll use almost the same technique to build a car as you would build a bus. 01:29.340 --> 01:35.100 Except that they'll be of different sizes and number of seats so why don't we reuse the construction 01:35.100 --> 01:36.150 process. 01:36.150 --> 01:39.080 This is where the builder pattern comes to the rescue. 01:39.300 --> 01:46.560 A builder design pattern tries to abstract complex creations so that object creation is separated from 01:46.560 --> 01:54.000 the object user creates an object step by step by filling its fields and creating the embedded objects 01:54.120 --> 01:58.590 reuse the object creation algorithm between many objects. 01:58.590 --> 02:01.500 Let's take an example of vehicle manufacturing. 02:01.500 --> 02:08.040 So the builder design pattern has been commonly described as the relationship between a director a few 02:08.040 --> 02:11.060 builders and the product they build. 02:11.070 --> 02:16.080 Continuing with our example of the car will create a vehicle builder. 02:16.140 --> 02:20.760 The process of creating a vehicle is more or less the same for every kind of vehicle. 02:20.880 --> 02:26.340 Choose a vehicle type assemble the structure placed the wheels and placed the seats. 02:26.400 --> 02:30.320 If you think about it you could build a car and a motorbike or two builders. 02:30.420 --> 02:36.020 With this description so we are reusing the description to create cars in manufacturing. 02:36.090 --> 02:39.740 The director is represented by the manufacturing director type. 02:39.870 --> 02:41.320 In our example. 02:41.640 --> 02:45.930 Now let's see what are the requirements and acceptance criteria. 02:46.200 --> 02:53.340 As far as we have described we must dispose of a builder of type Car and a motorbike and a unique director 02:53.340 --> 02:58.570 called Manufacturing director to take builders and construct products. 02:58.770 --> 03:03.680 So the requirements for a vehicle builder example would be as listed here. 03:03.900 --> 03:10.280 I must have a manufacturing type that constructs everything that a vehicle needs when using a car builder. 03:10.340 --> 03:17.040 The vehicle product with four wheels five seats and a structure defined as car must be returned. 03:17.040 --> 03:22.920 When using a motorbike builder the vehicle product with two wheels two seats and a structure defined 03:22.920 --> 03:30.360 as motor bike must be returned a vehicle product built by any build process builder must be open to 03:30.360 --> 03:31.970 modifications. 03:32.040 --> 03:35.520 Let's move on to the unit test for the vehicle builder. 03:35.520 --> 03:41.510 With the previous acceptance criteria we will create a director variable the manufacturing director 03:41.520 --> 03:48.330 type to use the build process represented by the product builder variables free car and motorbike. 03:48.330 --> 03:53.070 The director is the one in charge of construction of the objects but the builders are the ones that 03:53.070 --> 03:54.720 return the actual vehicle. 03:54.780 --> 03:58.830 So our builder declaration will look as this. 03:58.830 --> 04:03.000 This interface defines the steps that are necessary to build a vehicle. 04:03.000 --> 04:09.420 Every builder must implement this interface if they are to be used by the manufacturing on every set 04:09.420 --> 04:10.050 step. 04:10.050 --> 04:15.840 We return the same build process so we can chain various steps together in the same statement as we'll 04:15.840 --> 04:16.470 see later. 04:17.040 --> 04:22.350 Finally we'll need a get vehicle method to retrieve the vehicle instance from the builder. 04:22.500 --> 04:28.600 So we have added this method here which you can see highlighted the manufacturing director variable 04:28.840 --> 04:31.660 is the one in charge of accepting the builders. 04:31.720 --> 04:37.780 It has a construct method that will use the builder that is stored in manufacturing and will reproduce 04:37.810 --> 04:43.450 the required steps the set builder method will allow us to change the builder that is being used in 04:43.450 --> 04:45.260 the manufacturing director. 04:45.460 --> 04:47.830 And here's the piece of code for it. 04:47.950 --> 04:53.150 Now the product is the final object that we want to retrieve while using the manufacturing. 04:53.290 --> 04:59.320 In this case a vehicle is composed of wheels seats and a structure as you see here. 04:59.440 --> 05:02.260 The first builder is the car builder. 05:02.260 --> 05:06.760 It must implement every method defined in the build process interface. 05:06.760 --> 05:10.160 This is where we'll set the information for this particular builder. 05:10.300 --> 05:17.020 Next the motorbike structure must be the same as the car structure as they are all builder implementations. 05:17.080 --> 05:20.930 But keep in mind that the process of building each can be very different. 05:21.040 --> 05:25.920 With this declaration of objects we can create the tests as I have done it here. 05:25.930 --> 05:30.340 Now let's move to the builder underscore test not go file. 05:30.340 --> 05:36.370 We will start with the manufacturing director and the car builder to fulfil the first two acceptance 05:36.370 --> 05:40.570 criteria in the preceding code we are creating our manufacturing director. 05:40.660 --> 05:44.560 That will be in charge of the creation of every vehicle during the test. 05:45.070 --> 05:51.490 After creating the manufacturing director we create a car builder that we then passed the manufacturing 05:51.520 --> 05:53.980 by using the set builder method. 05:53.980 --> 05:59.410 Once the manufacturing director knows what it has to construct now we can call the constructor method 05:59.410 --> 06:03.070 to create the vehicle product using car builder. 06:03.070 --> 06:08.260 Finally once we have all the pieces for our car we'll call the get to vehicle method. 06:08.260 --> 06:11.800 On car builder to retrieve a car instance. 06:12.160 --> 06:16.950 Now we have written three small tests to check if the outcome is a car. 06:16.990 --> 06:18.840 We check that the car has four wheels. 06:18.940 --> 06:23.950 The structure has the description car and the number of seats is five. 06:23.950 --> 06:29.290 We have enough data to execute the tests and make sure that they are failing so that we can consider 06:29.290 --> 06:33.960 them reliable let us move on to the terminal and execute the command. 06:33.960 --> 06:41.320 Go test IV and V hyphen run equal to test builder so you can see the output where the wheels of the 06:41.320 --> 06:49.740 car must be for and they were zero structure on a car must be car and was and the third one seats on 06:49.740 --> 06:57.890 a car must be five and they were zero perfect now we'll create tests for a motorbike builder that covers 06:57.900 --> 07:01.130 the third and or acceptance criteria. 07:01.130 --> 07:03.470 So let's go back to our test file. 07:03.470 --> 07:06.960 So here we have the code for bike builder. 07:06.980 --> 07:10.160 This code is a continuation of the car tests. 07:10.310 --> 07:15.410 As you can see we reuse the previously created manufacturing to create the bike. 07:15.410 --> 07:21.830 Now by passing the motorbike builder to it then we hit the construct button again to create necessary 07:21.830 --> 07:28.670 parts and called the builder get vehicle method to retrieve the motorbike instance take a quick look 07:28.910 --> 07:33.580 because we have changed the default number of seats for this particular motorbike to 1. 07:33.700 --> 07:39.080 Let us go back to the builder dot go file and make changes to the bike builder type. 07:39.110 --> 07:41.960 Let's change these values to 0. 07:41.960 --> 07:47.510 What we want to show here is that even while having a builder you must also be able to change the default 07:47.510 --> 07:53.840 information in the returned instance to fit some specific needs as we set the wheels manually. 07:53.870 --> 08:01.410 We want to test this feature Let's rerun the tests so it triggers the expected behavior as we can see 08:01.410 --> 08:02.700 here. 08:02.730 --> 08:09.450 Now let's start implementing the manufacturing as we said earlier the manufacturing director must accept 08:09.450 --> 08:16.440 a builder and construct a vehicle using the provided builder to recall the build process interface will 08:16.440 --> 08:22.800 define the common steps needed to construct any vehicle and the manufacturing director must accept builders 08:22.890 --> 08:25.720 and construct vehicles together with them. 08:25.740 --> 08:31.860 So we have made the changes and we have added the code as you see wheels equal to four seats equal to 08:31.860 --> 08:40.200 five and structure equal to car and the seats for bike is to our manufacturing director needs a field 08:40.230 --> 08:42.160 to store the builder in use. 08:42.300 --> 08:47.850 This field will be called builder the set builder method will replace the stored builder with the one 08:47.850 --> 08:49.730 provided in the arguments. 08:49.730 --> 08:52.850 Finally take a closer look at the construct method. 08:52.920 --> 08:58.140 It takes the builder that has been stored and reproduces the build process method that will create a 08:58.140 --> 09:00.380 full vehicle of some unknown type. 09:00.510 --> 09:04.580 As you can see we have used all the settings calls in the same line. 09:04.620 --> 09:12.020 Thanks to returning the build process interface on each of the calls this way the code is more compact. 09:12.030 --> 09:17.490 Have you realized that the director entity and the builder pattern is a clear candidate for a singleton 09:17.490 --> 09:18.880 pattern too. 09:18.990 --> 09:24.480 In some scenarios it could be critical that just an instance of the director is available and that is 09:24.480 --> 09:28.760 where you'll create a singleton pattern for the director of the builder only. 09:29.130 --> 09:30.040 Design Patterns. 09:30.040 --> 09:34.710 Composition is a very common technique and a very powerful one. 09:34.740 --> 09:38.930 I've already shown you the changes that I made to this code. 09:38.940 --> 09:45.780 Here is our first builder the car builder a builder will need to store a vehicle product object which 09:45.780 --> 09:47.600 here we have named V. 09:47.640 --> 09:53.910 Then we set the specific needs that a car has in our business four wheels five seats and a structure 09:53.910 --> 09:57.510 defined as car in the get vehicle method. 09:57.540 --> 10:00.930 We just returned the vehicle product stored within the builder. 10:00.930 --> 10:05.430 That must be already constructed by the manufacturing director type. 10:05.430 --> 10:09.480 Now the motorbike builder is the same as the car builder. 10:09.540 --> 10:15.430 We defined a motorbike to have two wheels two seats and a structure called motorbike. 10:15.450 --> 10:21.030 It's very similar to the car object but imagine that you want to differentiate between a sports motorbike 10:21.240 --> 10:25.520 with only one seat and a Cruz motorbike with two seats. 10:25.590 --> 10:31.310 You could simply create a new structure for sports motorbikes that implements the build process. 10:31.380 --> 10:36.450 You can see that it's a repetitive pattern but within the scope of every method of the build process 10:36.570 --> 10:40.530 interface you could encapsulate as much complexity as you want. 10:40.530 --> 10:47.230 Such that the user need not know the details about the object creation with the definition of all the 10:47.230 --> 10:49.810 objects let's run the test again. 10:50.020 --> 10:52.270 So we've passed the test. 10:52.270 --> 10:53.370 Well done. 10:53.410 --> 10:59.200 Think how easy it could be to add new vehicles to the manufacturing director just to create a new class 10:59.200 --> 11:01.830 encapsulating the data for the new vehicle. 11:02.080 --> 11:08.740 For example here we add a bus builder struct that's all your manufacturing director would be ready to 11:08.740 --> 11:12.680 use the new product by following the builder design pattern. 11:12.740 --> 11:19.570 Let's save the file go to the builder design pattern helps us maintain an unpredictable number of products 11:19.840 --> 11:24.210 by using a common construction algorithm that is used by the director. 11:24.430 --> 11:29.500 The construction process is always abstracted from the user of the product. 11:29.500 --> 11:34.960 At the same time having defined a construction pattern helps when a newcomer to our source code needs 11:34.960 --> 11:37.580 to add a new product to the pipeline. 11:37.690 --> 11:43.390 The build process interface specifies what he must comply to be part of the possible builders. 11:43.600 --> 11:48.970 However try to avoid the builder pattern when you are not completely sure that the algorithm is going 11:48.970 --> 11:54.940 to be more or less stable because any small change in this interface will affect all your builders and 11:54.940 --> 12:00.820 it could be awkward if you add a new method that some of your builders need and other builders do not 12:02.140 --> 12:03.040 in this video. 12:03.070 --> 12:07.170 We explored about the builder design pattern in the next video. 12:07.240 --> 12:09.670 We will be learning about factory method.