WEBVTT 00:00.650 --> 00:07.050 I welcome to a new section of this video course creation all patterns in this section. 00:07.050 --> 00:12.930 We will start with Singleton design pattern having a unique instance of a type in the entire program 00:13.200 --> 00:18.720 and then we'll move on to build a design pattern where we'll be reusing an algorithm to create many 00:18.720 --> 00:20.960 implementations of an interface. 00:21.150 --> 00:27.270 Then we will explore about factory method delegating the creation of different types of payments and 00:27.270 --> 00:29.780 then we'll dive into Abstract Factory. 00:29.910 --> 00:32.910 Or we could say a factory of factories. 00:32.940 --> 00:36.860 Finally we will have a look at prototype design pattern. 00:36.870 --> 00:42.360 Now we move on to the first video of the section that deals with Singleton design pattern. 00:42.360 --> 00:49.020 In this video we will first have the description and objective and take an example of a unique counter. 00:49.020 --> 00:54.460 Then we'll see what are the requirements and acceptance and criteria at the end. 00:54.480 --> 00:58.750 We will learn the implementation of Singleton patterns. 00:58.770 --> 01:02.780 Have you ever gone through interviews as a software engineer. 01:02.790 --> 01:09.060 It's interesting that when candidates are asked about design patterns more than 80 percent will mention 01:09.210 --> 01:11.190 Singleton design pattern. 01:11.190 --> 01:12.570 Why is that. 01:12.570 --> 01:19.020 Maybe it's because it is one of the most used design patterns out there or one of the easiest to grasp. 01:19.080 --> 01:24.270 We will start our journey on creation or design patterns because of that latter reason. 01:24.720 --> 01:30.390 The Singleton pattern is easy to remember as the name implies it will provide you with a single instance 01:30.390 --> 01:36.750 of an object and guarantee that there are no duplicates at the first call to use the instance it is 01:36.750 --> 01:43.140 created and then reused between all the parts of the application that need to use that particular behavior. 01:43.380 --> 01:46.620 You'll use singleton pattern in many different situations. 01:46.740 --> 01:52.680 For example when you want to use the same connection to a database to make every query when you open 01:52.680 --> 01:59.580 a secure shell that is s s h connection to a server to do a few tasks and don't want to reopen the connection 01:59.580 --> 02:00.940 for each task. 02:01.260 --> 02:07.020 If you need to limit the access to some variable or space you use a singleton as the door to this variable. 02:07.020 --> 02:12.180 If you need to limit the number of calls to some places you create a singleton instance to make the 02:12.180 --> 02:14.660 calls in the accepted window. 02:14.700 --> 02:20.400 The possibilities are endless and we have just mentioned some of them as a general guide. 02:20.460 --> 02:24.330 We consider using the Singleton pattern when these rules apply. 02:24.360 --> 02:30.840 We need a single shared value of some particular type and we need to restrict object creation of some 02:30.840 --> 02:34.950 type to a single unit along the entire program. 02:34.950 --> 02:41.670 Now let's take an example of a unique counter as an example of an object of which we must ensure that 02:41.670 --> 02:46.890 there is only one instance we will write a counter that holds the number of times it has been called 02:47.040 --> 02:49.350 during program execution. 02:49.350 --> 02:51.950 It shouldn't matter how many instance we have of the counter. 02:52.110 --> 02:58.580 All of them must count the same value and it must be consistent between the instances. 02:58.770 --> 03:04.470 There are some requirements and acceptance criteria to write the described single counter they're listed 03:04.620 --> 03:11.200 here when no counter has been created before a new one is created with the value 0. 03:11.210 --> 03:16.920 If a counter has already been created returned this instance that holds the actual count. 03:17.120 --> 03:22.230 If we call the method add one The Count must be incremented by 1. 03:22.280 --> 03:27.250 We have a scenario with three tests to check in our unit tests. 03:27.260 --> 03:29.410 Now let's jump into writing unit tests. 03:29.420 --> 03:35.030 First goes implementation of this pattern is slightly different from what you'll find in pure object 03:35.120 --> 03:41.230 oriented languages such as Java or C++ where you have static members in go. 03:41.360 --> 03:47.450 There's nothing like static members but we have package scope to deliver a similar result to set up 03:47.450 --> 03:48.210 our project. 03:48.230 --> 03:52.520 We must create a new folder within our go path source directory. 03:52.550 --> 03:57.920 The general rule as we mentioned in the first section is to create a sub folder with the VCR provider 03:58.130 --> 04:02.620 such as GetUp the user name and the name of the project. 04:02.780 --> 04:11.420 For example in my case I use get hub as my VCR s and my username is FE So I will create the path go 04:11.420 --> 04:21.200 path slash source get hub dot com slash pay go design patterns relational slash Singleton the go design 04:21.200 --> 04:27.950 patterns instance in the path is the project name the creation or sub folder will also be our library 04:27.950 --> 04:33.060 name and Singleton the name of this particular package and sub folder. 04:33.290 --> 04:40.460 So let's create the Singleton folder type the command make directory iPhone P followed by the path which 04:40.460 --> 04:42.630 I just mentioned done. 04:42.890 --> 04:46.650 Now let's see the the same go path next. 04:46.850 --> 04:52.970 Create a new file inside the Singleton folder called Singleton dot go to also reflect the name of the 04:52.970 --> 04:59.180 package and write the package declarations for the Singleton type let's write the command Nanos Singleton 04:59.180 --> 05:07.940 dot go now at GM new Nano let's add the package declaration lets me align the code lines properly okay 05:08.810 --> 05:17.300 first let's save this file using control Oh and now control X as we are following a TDD approach while 05:17.300 --> 05:22.480 writing the code let's code the tests that use the functions we have just declared. 05:22.490 --> 05:27.230 The tests are going to be defined by following the acceptance criteria that we have written earlier 05:27.480 --> 05:34.430 by convention in test files we must create a file with the same name as the file to test suffixes with 05:34.430 --> 05:39.020 the underscore test dot go both must reside in the same folder. 05:39.140 --> 05:47.210 So let's create the test file nano Singleton underscore test dot go at these lines of code to this file 05:48.490 --> 05:53.660 the first test check something obvious but no less important in complex applications. 05:53.710 --> 05:57.610 We actually received something when we asked for an instance of the counter. 05:57.610 --> 06:00.570 We have to think of it as a creation or pattern. 06:00.670 --> 06:06.250 We delegate the creation of the object to an unknown package that could fail in the creation or retrieval 06:06.250 --> 06:07.390 of the object. 06:07.420 --> 06:13.780 We also store the current counter in the expected counter variable to make a comparison later. 06:13.780 --> 06:16.960 Let's add the code for the current account logic. 06:16.990 --> 06:21.120 Now we take advantage of the zero initialization feature of Go. 06:21.310 --> 06:25.080 Remember that integer types in go cannot be nil. 06:25.120 --> 06:30.470 And as we know that this is the first call to the counter and it is an integer type of variable. 06:30.550 --> 06:33.610 And we also know it is 0 initialized. 06:33.610 --> 06:39.110 So after the first call to the add one function the value of the count must be 1. 06:39.340 --> 06:44.860 The test that checks the second condition provides that the expected connection variable is not different 06:44.980 --> 06:47.810 to the return connection that we requested later. 06:48.100 --> 06:54.850 If they were different the message Singleton instances must be different will cause the test to fail. 06:54.880 --> 07:00.810 Let's add the code for counter to the last test is simply counting 1. 07:00.840 --> 07:04.550 Again with the second instance the previous result was 1. 07:04.560 --> 07:10.860 So now it must give us do the last thing we have to do to finish our test part is to execute the test 07:10.860 --> 07:14.130 to make sure that they are failing before implementation. 07:14.130 --> 07:20.190 If one of them doesn't fail it implies we have done something wrong and we have to reconsider that particular 07:20.190 --> 07:21.180 test. 07:21.200 --> 07:22.920 Let us save the file. 07:22.920 --> 07:29.550 Now we must open the terminal and navigate to the path of the singleton package to execute right at 07:29.550 --> 07:30.360 the terminal. 07:30.360 --> 07:34.260 Go test iPhone V and click enter. 07:34.290 --> 07:36.620 So here is the output also. 07:37.230 --> 07:40.380 Now let's move on to the implementation. 07:40.410 --> 07:43.700 Finally we have to implement the Singleton pattern. 07:43.890 --> 07:49.230 As we mentioned earlier we'll usually write a static method in an instance to retrieve the Singleton 07:49.320 --> 07:54.180 instance in languages such as Java or C++ in go. 07:54.180 --> 08:00.400 We don't have the keyword static but we can achieve the same result by using the scope of the package. 08:00.540 --> 08:06.150 First we create a struct that contains the object which we want to guarantee to be a singleton during 08:06.150 --> 08:08.760 the execution of the program. 08:08.760 --> 08:15.840 Let's open our file navigate to the go directory source then get hub dot com and open the Singleton 08:15.840 --> 08:19.420 dot file from the directory where you have saved it. 08:19.470 --> 08:21.270 Let's replace this code. 08:21.420 --> 08:23.790 Let me align the code lines. 08:23.790 --> 08:31.960 Now save the file you must pay close attention to this piece of code in languages such as Java or C++. 08:32.000 --> 08:38.070 The variable instance would be initialized to know at the beginning of the program in go. 08:38.090 --> 08:44.810 You can initialize a pointer to a struct as nil but you cannot initialize a structure to nil which is 08:44.810 --> 08:46.520 the equivalent of no. 08:46.520 --> 08:53.720 So the VAR instance asterisk Singleton line defines a pointer to a struct of type Singleton as nil and 08:53.750 --> 08:55.830 the variable called instance. 08:56.150 --> 09:02.810 We created a get instance method that checks if the instance has not been initialized already instance 09:02.900 --> 09:10.430 equal to equal to nil and creates an instance in the space already allocated in the line instance equal 09:10.430 --> 09:12.220 to new Singleton. 09:12.260 --> 09:18.140 Remember when we use the keyword new we are creating a pointer to an instance of the type between the 09:18.140 --> 09:25.110 parentheses the add one method will take the count of the variable instance raise it by 1 and return 09:25.110 --> 09:27.240 the current value of the counter. 09:27.240 --> 09:33.450 So before executing this code remember to change the package name in the Singleton underscore test dot 09:33.600 --> 09:39.600 go to creation all since the package name in the Singleton dot go is also creation all. 09:39.780 --> 09:43.400 Let's save this file and go back to the terminal. 09:43.530 --> 09:48.160 Let's run now our unit test again and here's the output. 09:48.480 --> 09:55.260 A few words about the Singleton design pattern we have seen a very simple example of the Singleton pattern 09:55.500 --> 09:59.910 partially applied to some situation that is a simple counter. 09:59.910 --> 10:05.070 Just keep in mind that the Singleton pattern will give you the power to have a unique instance of some 10:05.070 --> 10:12.490 struct in your application and that no package can create any clone of this struct before in this video. 10:12.510 --> 10:16.440 Let's have a few words about the Singleton pattern with Singleton. 10:16.450 --> 10:22.800 You're also hiding the complexity of creating the object in case it requires some computation and the 10:22.800 --> 10:26.300 pitfall of creating it every time you need an instance of it. 10:26.310 --> 10:32.550 If all of them are similar all this code writing checking if the variable already exists and storage 10:32.730 --> 10:36.710 are encapsulated in the Singleton and you won't need to repeat it everywhere. 10:36.720 --> 10:43.080 If you use a global variable here we are learning the classic Singleton implementation for single threaded 10:43.080 --> 10:44.310 context. 10:44.310 --> 10:49.530 We will see a concurrent Singleton implementation when we reach the sections about concurrency. 10:49.590 --> 10:56.220 In the last part of this video course because this implementation is not thread safe in this video we 10:56.220 --> 11:00.330 have learned about the Singleton design pattern in the next video. 11:00.330 --> 11:03.060 We will have a look at the builder design pattern.