This is the third video of this sanction facade design pattern.
Previously we learned about the decorator design pattern in this video.
We will learn to write our own library that access is open weather map service a facade in architectural
terms is the front wall that hides the rooms and corridors of a building.
It protects its inhabitants from cold and rain and provides them privacy.
It orders and divides the dwellings.
The facade design pattern does the same but in our code it shields the code from unwanted access orders
some calls and hides the complexity scope from the user.
You use facade when you want to hide the complexity of some tasks especially when most of them share
utilities such as authentication in an API.
A library is a form of facade where someone has to provide some methods for a developer to do certain
things in a friendly way.
This way if a developer needs to use your library it doesn't need to know all the and tasks to retrieve
the result he or she wants.
So you use facade design pattern in these scenarios when you want to decrease the complexity of some
parts of our code.
You hide that complexity behind the facade by providing a more easy to use method.
Also when you wanted to group actions that are cross related in a single place.
And lastly when you want to build a library so that others can use your product without worrying about
how it all works.
As an example we're going to take the first steps towards writing our own library.
That access is open weather maps service in case you're not familiar with open weather map service it
is an HDTV service that provides you with live information about weather as well as historical data
on it.
The 8th TTP REST API is very easy to use and will be a good example on how to create a facade pattern
for hiding the complexity of the network connections behind the rest.
Service the open weather map API gives lots of information so we are going to focus on getting life
weather data in one city in some geo located place by using its latitude and longitude values.
Here are the requirements and acceptance criteria for this design pattern.
First of all to provide a single type to access the data all information retrieved from open weather
map service will pass through it.
Next create a way to get the weather data for some city of some country.
Then create a way to get the weather data for some latitude and longitude position.
And lastly only second and third point must be visible outside the package.
Everything else must be hidden including all connection related data.
Now let's move on to the unit test to start with our API facade.
We will need an interface with the methods asked in acceptance criteria too and acceptance criteria.
3.
Let me open the facade.
Dot go file to explain the code
here.
We will call acceptance criteria to get by city and country code.
We will also need a city name and a country code in the string format a country code is a two character
code which represents the International Organization for Standardization that is ISO name of world countries.
It returns a weather value which we will define later and an error.
If something goes wrong acceptance criteria 3 will be called get by geo coordinates and will need latitude
and longitude values in the float 30 format.
It will also return a weather value and an error.
The weather value is going to be defined according to the returned Jason that the open weather map API
works with.
You can find the description of this Jason at the web page.
Open weather map.
Dot org.
Here you can get all the descriptions.
Let's go back to the code file.
If you look at the Jason definition it has this type it's quite a long struct but we have everything
that a response could include the struct is cold weather as it is composed of an I.D. a name a code
or c o d and a few anonymous structures which are c o o r d whether base main wind clouds rain D.T.
and CIS we could write these anonymous struct outside of the weather struct by giving them a name but
it would only be useful if we have to work with them separately.
After every member and struct within our weather struct you can find a Jason Cole on something.
This comes in handy when differentiating between the Jason key name and your member name.
If the Jason key is something we aren't forced to call our member something for example our I.D. member
will be called I.D. in the Jason response.
Why don't we give the name of the Jason keys to our types.
Well if your fields and your type are lower case the encoding slash Jason package won't pass them correctly.
Also that last annotation provides us with a certain flexibility not only in terms of changing the members
names but also omitting some key if we don't need it with the signature.
Let me show you how this signature looks with Emmitt empty at the end the pass won't fail.
If this key is not present in the bytes representation of the Jason key.
Okay.
Our acceptance criteria one asks for a single point of access to the API.
This is going to be called Current weather data.
The current weather data type has an API key as public member to work.
This is because you have to be a registered user in open weather map to enjoy their services.
Refer to the open weather map API is web page for documentation on how to get an API key.
We won't need it in our example because we aren't going to do integration tests.
We need mock data so that we can write a mock function to retrieve the data when sending an H TTP request.
The response is contained in a member called body in the form of an IO dot reader.
We've already worked with types that implement the IO dot reader interface.
So this should look familiar to you.
Let me show you how our mock function appears
this mocked.
Data was produced by making a request to open weather map using an API key.
The response variable is a string containing a Jason response.
Take a close look at the grave accent used to open and close the string.
This way you can use as many quotes as you want without any problems.
Further on we use a special function in the bytes package called new reader which accepts a slice of
bytes which we create by converting the type from string and returns and Io dot reader implementer with
the contents of the slice.
This is perfect to mimic the body member of an H TTP response.
Next we write a test to try response parser.
Both methods return the same type so we can use the same Jason parser for both in this test which you
see highlighted.
We first asked for some mock data which we store in the variable R later.
We created a type of current weather data which we called open weather map.
Finally we asked for a weather value for the provider Io dot reader interface that we store in the variable
weather.
After checking for errors we make sure that the idea is the same as the one stored in the mock data
that we got from the get mock data method.
We have also declared the response parser method before running tests or the code won't compile with
all these we can run this test.
Let's open the terminal and run the test and here's the output.
As you can see that the test failed.
Okay we won't write more tests because the rest would be merely integration tests which are outside
of the scope of explanation of a structural pattern and will force us to have an API key as well as
an Internet connection.
If you want to see what the integration tests look like for this example refer to the code that comes
bundled with the course.
First of all we are going to implement the parser that our methods will use to pass the Jason response
from the open weather map.
Rest Api let's open the facade test go and replace this piece of code.
Now save the file and this should be enough to pass the test by now.
So as we run this test we get this output and we have passed the test.
At last we have our past a well tested.
Let's structure our code to look like a library.
First we will create the methods to retrieve the weather of a city by its name and its country code
and the method that uses its latitude and longitude.
Let's go back to facades.
Dot go here.
Let's add the function for current weather data.
Let me set the indentation a piece of cake.
Of course everything must be as easy as possible and it is a sign of a good job.
The complexity in this facade is to create connections to the open weather map API and control the possible
errors.
This problem is shared between all the facade methods in our examples so we don't need to write more
than one API call right now what we do is pass the U.R.L. that the rest api needs in order to return
the information we desire.
This is achieved by half empty dot Sprint f function which formats the strings in each case for example
to together the data using a city name and a country code.
We use this string this takes the pre formatted string H TTP s Cole on open weather map.
Dot org slash API and format set by replacing each Ampersand as specified with the city the country
code that we introduced in the arguments and the API key member of the current weather data type.
But we haven't set any API key.
Yes because this is a library and the uses of the library will have to use their own API keys.
We are hiding the complexity of creating the You Are L's and handling the errors.
Finally the do request function is a big fish so we will see it in detail step by step.
First the signature tells us that the do request method at set a new are rice string and returns appointed
to the weather variable and an error.
We start by creating an H TTP.
Dot.
Client class which will make the requests.
Then we create a request object which will use the get method as described in the open weather map.
Web page and the you are right.
We passed.
If we were to use a different method or get more than one they would have to be brought about by arguments
in the signature.
Nevertheless we will use just the get method so we could hardcoded their then we check whether the request
object has been created successfully and set a header that says that the content type is a Jason let
us continue by adding the code then we make the request and check for errors with this code because
we have given names to our return types.
If any error occurs we just have to return the function and go will return the variable error and the
variable whether in the state that they were in at that precise moment we check the status code of the
response as we only accept 200 as a good response.
If two hundred isn't returned we will create an error message with the contents of the body and the
status code returned.
Now let's add the response parser finally.
If everything goes well we use the response parser function we wrote earlier to pass the contents of
body which is an IO dot reader interface.
Maybe you were wondering why we aren't controlling air from the response parser method.
It's funny because we are actually controlling it.
Response parser and do request have the same return signature both return to whether pointer and an
error if any so we can return directly whatever the result was cool.
Now let's have a look at the library created with the facade pattern.
We have the first milestone for a library for the open weather map API.
Using the facade pattern we have hidden the complexity of accessing the open weather map rest api in
the do request and response parser functions and the uses of our library have an easy to use syntax
to query the API for example to retrieve the weather from Madrid Spain.
A user will only have to introduce arguments and an API key at the beginning the console output for
the weather in Madrid at the moment of recording this course is here.
A typical summer day.
Superb.
In this video we explored about facade design pattern in the next video.
We will have a look at flyweight design pattern.