WEBVTT 00:00.360 --> 00:05.520 This is the third video of this sanction facade design pattern. 00:05.550 --> 00:10.000 Previously we learned about the decorator design pattern in this video. 00:10.020 --> 00:17.130 We will learn to write our own library that access is open weather map service a facade in architectural 00:17.130 --> 00:21.490 terms is the front wall that hides the rooms and corridors of a building. 00:21.630 --> 00:26.550 It protects its inhabitants from cold and rain and provides them privacy. 00:26.610 --> 00:29.400 It orders and divides the dwellings. 00:29.400 --> 00:36.200 The facade design pattern does the same but in our code it shields the code from unwanted access orders 00:36.210 --> 00:40.950 some calls and hides the complexity scope from the user. 00:40.950 --> 00:46.920 You use facade when you want to hide the complexity of some tasks especially when most of them share 00:46.920 --> 00:50.800 utilities such as authentication in an API. 00:50.850 --> 00:56.160 A library is a form of facade where someone has to provide some methods for a developer to do certain 00:56.160 --> 00:58.260 things in a friendly way. 00:58.350 --> 01:04.380 This way if a developer needs to use your library it doesn't need to know all the and tasks to retrieve 01:04.380 --> 01:06.650 the result he or she wants. 01:06.690 --> 01:13.050 So you use facade design pattern in these scenarios when you want to decrease the complexity of some 01:13.050 --> 01:14.410 parts of our code. 01:14.460 --> 01:20.370 You hide that complexity behind the facade by providing a more easy to use method. 01:20.400 --> 01:24.830 Also when you wanted to group actions that are cross related in a single place. 01:24.990 --> 01:30.660 And lastly when you want to build a library so that others can use your product without worrying about 01:30.660 --> 01:32.400 how it all works. 01:32.610 --> 01:37.590 As an example we're going to take the first steps towards writing our own library. 01:37.590 --> 01:43.710 That access is open weather maps service in case you're not familiar with open weather map service it 01:43.710 --> 01:49.560 is an HDTV service that provides you with live information about weather as well as historical data 01:49.590 --> 01:50.440 on it. 01:50.490 --> 01:57.780 The 8th TTP REST API is very easy to use and will be a good example on how to create a facade pattern 01:57.930 --> 02:01.530 for hiding the complexity of the network connections behind the rest. 02:01.530 --> 02:08.560 Service the open weather map API gives lots of information so we are going to focus on getting life 02:08.580 --> 02:16.230 weather data in one city in some geo located place by using its latitude and longitude values. 02:16.230 --> 02:21.000 Here are the requirements and acceptance criteria for this design pattern. 02:21.030 --> 02:27.180 First of all to provide a single type to access the data all information retrieved from open weather 02:27.180 --> 02:29.730 map service will pass through it. 02:29.730 --> 02:34.760 Next create a way to get the weather data for some city of some country. 02:35.040 --> 02:40.680 Then create a way to get the weather data for some latitude and longitude position. 02:40.680 --> 02:45.930 And lastly only second and third point must be visible outside the package. 02:45.930 --> 02:51.440 Everything else must be hidden including all connection related data. 02:51.440 --> 02:56.750 Now let's move on to the unit test to start with our API facade. 02:56.750 --> 03:03.040 We will need an interface with the methods asked in acceptance criteria too and acceptance criteria. 03:03.050 --> 03:04.020 3. 03:04.040 --> 03:05.250 Let me open the facade. 03:05.260 --> 03:07.370 Dot go file to explain the code 03:12.040 --> 03:12.510 here. 03:12.530 --> 03:17.850 We will call acceptance criteria to get by city and country code. 03:17.870 --> 03:24.140 We will also need a city name and a country code in the string format a country code is a two character 03:24.140 --> 03:31.990 code which represents the International Organization for Standardization that is ISO name of world countries. 03:32.030 --> 03:35.860 It returns a weather value which we will define later and an error. 03:35.900 --> 03:43.700 If something goes wrong acceptance criteria 3 will be called get by geo coordinates and will need latitude 03:43.790 --> 03:47.390 and longitude values in the float 30 format. 03:47.390 --> 03:50.330 It will also return a weather value and an error. 03:50.600 --> 03:56.090 The weather value is going to be defined according to the returned Jason that the open weather map API 03:56.090 --> 03:57.360 works with. 03:57.440 --> 04:00.770 You can find the description of this Jason at the web page. 04:00.830 --> 04:01.850 Open weather map. 04:01.850 --> 04:03.170 Dot org. 04:03.170 --> 04:06.140 Here you can get all the descriptions. 04:06.230 --> 04:07.760 Let's go back to the code file. 04:08.510 --> 04:17.120 If you look at the Jason definition it has this type it's quite a long struct but we have everything 04:17.120 --> 04:24.140 that a response could include the struct is cold weather as it is composed of an I.D. a name a code 04:24.290 --> 04:35.360 or c o d and a few anonymous structures which are c o o r d whether base main wind clouds rain D.T. 04:35.600 --> 04:42.650 and CIS we could write these anonymous struct outside of the weather struct by giving them a name but 04:42.650 --> 04:46.350 it would only be useful if we have to work with them separately. 04:46.550 --> 04:54.890 After every member and struct within our weather struct you can find a Jason Cole on something. 04:54.920 --> 05:01.040 This comes in handy when differentiating between the Jason key name and your member name. 05:01.070 --> 05:07.550 If the Jason key is something we aren't forced to call our member something for example our I.D. member 05:07.700 --> 05:11.340 will be called I.D. in the Jason response. 05:11.570 --> 05:16.070 Why don't we give the name of the Jason keys to our types. 05:16.070 --> 05:24.560 Well if your fields and your type are lower case the encoding slash Jason package won't pass them correctly. 05:24.620 --> 05:30.950 Also that last annotation provides us with a certain flexibility not only in terms of changing the members 05:30.950 --> 05:36.710 names but also omitting some key if we don't need it with the signature. 05:36.710 --> 05:44.510 Let me show you how this signature looks with Emmitt empty at the end the pass won't fail. 05:44.520 --> 05:48.940 If this key is not present in the bytes representation of the Jason key. 05:49.760 --> 05:50.410 Okay. 05:50.520 --> 05:55.750 Our acceptance criteria one asks for a single point of access to the API. 05:55.770 --> 05:58.770 This is going to be called Current weather data. 05:58.830 --> 06:03.440 The current weather data type has an API key as public member to work. 06:03.450 --> 06:08.950 This is because you have to be a registered user in open weather map to enjoy their services. 06:09.180 --> 06:15.570 Refer to the open weather map API is web page for documentation on how to get an API key. 06:15.660 --> 06:20.770 We won't need it in our example because we aren't going to do integration tests. 06:20.880 --> 06:28.170 We need mock data so that we can write a mock function to retrieve the data when sending an H TTP request. 06:28.170 --> 06:34.140 The response is contained in a member called body in the form of an IO dot reader. 06:34.150 --> 06:38.080 We've already worked with types that implement the IO dot reader interface. 06:38.190 --> 06:40.620 So this should look familiar to you. 06:40.650 --> 06:42.990 Let me show you how our mock function appears 06:47.720 --> 06:48.410 this mocked. 06:48.410 --> 06:53.190 Data was produced by making a request to open weather map using an API key. 06:53.250 --> 06:57.380 The response variable is a string containing a Jason response. 06:57.410 --> 07:02.970 Take a close look at the grave accent used to open and close the string. 07:02.990 --> 07:07.460 This way you can use as many quotes as you want without any problems. 07:07.460 --> 07:13.730 Further on we use a special function in the bytes package called new reader which accepts a slice of 07:13.730 --> 07:20.510 bytes which we create by converting the type from string and returns and Io dot reader implementer with 07:20.510 --> 07:22.910 the contents of the slice. 07:22.910 --> 07:28.230 This is perfect to mimic the body member of an H TTP response. 07:28.360 --> 07:32.040 Next we write a test to try response parser. 07:32.260 --> 07:39.040 Both methods return the same type so we can use the same Jason parser for both in this test which you 07:39.040 --> 07:40.050 see highlighted. 07:40.120 --> 07:46.790 We first asked for some mock data which we store in the variable R later. 07:46.800 --> 07:52.190 We created a type of current weather data which we called open weather map. 07:52.200 --> 07:58.860 Finally we asked for a weather value for the provider Io dot reader interface that we store in the variable 07:58.980 --> 07:59.960 weather. 08:00.240 --> 08:05.130 After checking for errors we make sure that the idea is the same as the one stored in the mock data 08:05.160 --> 08:08.850 that we got from the get mock data method. 08:08.850 --> 08:16.050 We have also declared the response parser method before running tests or the code won't compile with 08:16.050 --> 08:18.070 all these we can run this test. 08:18.700 --> 08:22.660 Let's open the terminal and run the test and here's the output. 08:22.680 --> 08:25.380 As you can see that the test failed. 08:25.560 --> 08:31.650 Okay we won't write more tests because the rest would be merely integration tests which are outside 08:31.650 --> 08:37.080 of the scope of explanation of a structural pattern and will force us to have an API key as well as 08:37.080 --> 08:38.860 an Internet connection. 08:38.910 --> 08:44.220 If you want to see what the integration tests look like for this example refer to the code that comes 08:44.220 --> 08:46.020 bundled with the course. 08:46.020 --> 08:51.390 First of all we are going to implement the parser that our methods will use to pass the Jason response 08:51.600 --> 08:53.160 from the open weather map. 08:53.160 --> 08:58.920 Rest Api let's open the facade test go and replace this piece of code. 08:58.950 --> 09:04.070 Now save the file and this should be enough to pass the test by now. 09:04.110 --> 09:09.010 So as we run this test we get this output and we have passed the test. 09:09.210 --> 09:12.720 At last we have our past a well tested. 09:12.720 --> 09:15.780 Let's structure our code to look like a library. 09:15.900 --> 09:21.420 First we will create the methods to retrieve the weather of a city by its name and its country code 09:21.780 --> 09:25.500 and the method that uses its latitude and longitude. 09:25.530 --> 09:27.110 Let's go back to facades. 09:27.120 --> 09:29.270 Dot go here. 09:29.310 --> 09:32.190 Let's add the function for current weather data. 09:32.190 --> 09:36.040 Let me set the indentation a piece of cake. 09:36.120 --> 09:41.790 Of course everything must be as easy as possible and it is a sign of a good job. 09:41.790 --> 09:48.000 The complexity in this facade is to create connections to the open weather map API and control the possible 09:48.060 --> 09:49.010 errors. 09:49.020 --> 09:54.510 This problem is shared between all the facade methods in our examples so we don't need to write more 09:54.510 --> 10:02.440 than one API call right now what we do is pass the U.R.L. that the rest api needs in order to return 10:02.440 --> 10:04.280 the information we desire. 10:04.300 --> 10:11.710 This is achieved by half empty dot Sprint f function which formats the strings in each case for example 10:11.760 --> 10:15.020 to together the data using a city name and a country code. 10:15.040 --> 10:23.000 We use this string this takes the pre formatted string H TTP s Cole on open weather map. 10:23.000 --> 10:31.460 Dot org slash API and format set by replacing each Ampersand as specified with the city the country 10:31.460 --> 10:37.670 code that we introduced in the arguments and the API key member of the current weather data type. 10:37.940 --> 10:41.160 But we haven't set any API key. 10:41.300 --> 10:47.550 Yes because this is a library and the uses of the library will have to use their own API keys. 10:47.600 --> 10:53.000 We are hiding the complexity of creating the You Are L's and handling the errors. 10:53.000 --> 11:00.330 Finally the do request function is a big fish so we will see it in detail step by step. 11:00.530 --> 11:08.340 First the signature tells us that the do request method at set a new are rice string and returns appointed 11:08.390 --> 11:10.990 to the weather variable and an error. 11:11.030 --> 11:13.720 We start by creating an H TTP. 11:13.780 --> 11:14.120 Dot. 11:14.120 --> 11:17.330 Client class which will make the requests. 11:17.330 --> 11:23.060 Then we create a request object which will use the get method as described in the open weather map. 11:23.060 --> 11:24.770 Web page and the you are right. 11:24.770 --> 11:25.870 We passed. 11:26.120 --> 11:31.550 If we were to use a different method or get more than one they would have to be brought about by arguments 11:31.550 --> 11:32.500 in the signature. 11:32.870 --> 11:40.870 Nevertheless we will use just the get method so we could hardcoded their then we check whether the request 11:40.870 --> 11:47.710 object has been created successfully and set a header that says that the content type is a Jason let 11:47.710 --> 11:54.670 us continue by adding the code then we make the request and check for errors with this code because 11:54.670 --> 11:56.950 we have given names to our return types. 11:56.980 --> 12:03.430 If any error occurs we just have to return the function and go will return the variable error and the 12:03.430 --> 12:09.820 variable whether in the state that they were in at that precise moment we check the status code of the 12:09.820 --> 12:13.960 response as we only accept 200 as a good response. 12:14.080 --> 12:18.910 If two hundred isn't returned we will create an error message with the contents of the body and the 12:18.910 --> 12:21.010 status code returned. 12:21.010 --> 12:25.140 Now let's add the response parser finally. 12:25.230 --> 12:31.110 If everything goes well we use the response parser function we wrote earlier to pass the contents of 12:31.110 --> 12:34.980 body which is an IO dot reader interface. 12:34.980 --> 12:40.400 Maybe you were wondering why we aren't controlling air from the response parser method. 12:40.410 --> 12:43.260 It's funny because we are actually controlling it. 12:43.380 --> 12:49.770 Response parser and do request have the same return signature both return to whether pointer and an 12:49.890 --> 12:55.800 error if any so we can return directly whatever the result was cool. 12:55.800 --> 12:59.470 Now let's have a look at the library created with the facade pattern. 12:59.640 --> 13:03.960 We have the first milestone for a library for the open weather map API. 13:04.020 --> 13:10.770 Using the facade pattern we have hidden the complexity of accessing the open weather map rest api in 13:10.770 --> 13:17.280 the do request and response parser functions and the uses of our library have an easy to use syntax 13:17.280 --> 13:22.100 to query the API for example to retrieve the weather from Madrid Spain. 13:22.170 --> 13:29.250 A user will only have to introduce arguments and an API key at the beginning the console output for 13:29.250 --> 13:33.420 the weather in Madrid at the moment of recording this course is here. 13:33.420 --> 13:35.310 A typical summer day. 13:35.310 --> 13:36.390 Superb. 13:36.690 --> 13:42.090 In this video we explored about facade design pattern in the next video. 13:42.120 --> 13:44.840 We will have a look at flyweight design pattern.