All right, my friends, we've now finished up our first application in this video, I want to do a
quick review of the very important concepts we learned.
So the first important thing that we covered was that we wanted to restrict the amount of APIs surface
area exposed inside of index sites.
So in other words, if another engineer opened up our project and only had access to this file right
here, we wanted to limit the number of things that they could do.
They could only do things that you and I had specifically allowed inside of our application.
So, for example, another engineer could only create an instance of a user and read its name, property
and its location.
Another engineer could only create a company and then reference its company name, catchphrase and location.
And with a custom map, another engineer could only create an instance of a custom map and then call
that ad marker method in as far as our code is concerned.
That's the only thing that other engineers can do inside of here.
The most important aspect of this was that we wanted to restrict access to that Google map that we created
because remember, the Google map had a ton of different properties associated with it.
So to make sure that other engineers could not mess with this thing, we added on that private modifier.
The private modifier means that we can only reference this property from methods inside of the custom
map.
So, for example, back inside of inducts, if we tried to refer to a custom map Google map, we got
that error message that said this is a private property and you cannot access it unless you are inside
of the class custom map.
Now, I know 100 percent, I know what you're thinking, but in other engineers can just open up this
file and start calling this or accessing this property directly from inside this class.
Yes, I agree with you.
Another engineer could open up this file.
But the idea here was simply that if we viewed custom map as being like a black box or kind of like
a mystery thing of sorts, we limited the damage that other engineers can do.
So we just exposed the bare minimum amount of functionality to allow our application to work and nothing
more.
So another engineer absolutely can open up that file.
But if you just kind of view this variable right here by itself, there's only two things we can do
with it to create an instance and add a marker.
That's it.
Nothing else.
The next big thing we spoke about was our interface inside of custom map, so we ran into many issues
around this ad marker function.
We initially saw that we had two different ad marker functions, one for business or one for companies
and one for users.
And when we had that duplicate definition, well, we had a lot of duplicate code.
So as an initial approach, we tried to say that ad marker could take many different types.
So we had ad marker and we said that you could pass in a user or a company.
And then if we had additional types inside of application in the future, you could pass those in as
well.
And so the bad thing about this approach is that it set up a dependency between custom map and all the
different things that we would want to map inside of our application.
So as soon as we started to add in more things that could be represented on the map as a marker, well,
we had to go back and update custom map, which would have been a very easy time for us to accidentally
introduce bugs into our application.
So to fix this problem, we inverted the dependency here.
We said instead of custom map trying to accommodate all these different classes, we instead say, hey,
other classes you have to accommodate custom map.
So inside of custom map at the very top, we put some instructions on how another class or instance
of the class could be a argument to add marker.
We did that by defining an interface, so that was equivalent to custom map kind of standing up for
itself.
Custom map got up on a podium and it said to all the other classes inside of application, hey, other
classes, if you want to be an argument to add marker, here's what you have to do.
You have to define a location property that has the latitude as a number longitude.
That's a number marker content that returns a string and color that is a string as well.
Remember that we did not specifically have to update those classes until TypeScript, hey, I want my
user to be an instance of matchable.
We added this on only way later inside the application.
So we did not have to specifically say, hey, typescript, we want user to be an argument to add marker
instead.
As long as we had the correct properties, typescript did the appropriate checking for us invisibly
behind the scenes.
As soon as we tried to pass in user or company to add marker, TypeScript automatically took a look
at user and made sure it had the correct properties as long as it did.
Awesome thumbs up.
You can be an argument to add marker.
So again, the whole idea here was that we wanted our custom map to tell other classes what they had
to do to be an argument.
Now, the pattern you see right here is going to be a pattern that we repeat so many times again and
again and again and again, remember, I've told you many times that or at least once I should say that
in typescript, the big thing we want to learn and like the big killer feature of TypeScript, is the
interplay between classes and interfaces.
And that's exactly what you are seeing right here.
This right here.
This is the killer feature of TypeScript, and this is how we're going to write some code.
So just about every project that you and I work on is going to have an identical structure.
Every typescript file we work on is going to be something like this at the very top.
We're going to have a number of interface definitions.
Maybe it's one, two, three, four, however many.
And those definitions are going to describe what you have to do to work with the class.
So our class definition will have a couple of methods, and if a given method has to receive some other
object to work correctly, rather than specifying that other object type, we're going to instead specify
an interface.
So other objects inside of application can choose to implement that interface so they can work with
this class definition.
And that's how we're going to get this awesome amount of code we use and very low coupling between different
classes inside of application.
I can't say it enough, we're gonna see this pattern again and again, this is the whole point of this
course is to help you understand this pattern.
Well, a couple of things as well.
But you understand.
OK, one last big thing here, last we want to mention is that if we wanted to, we could help TypeScript
give us help.
So when we start working with this interface stuff, we want to make sure that we start to see errors
in the correct location.
So to help TypeScript show us errors in our interface, definitions in the correct spot, we can optionally
choose to implement an interface.
So instead of user teams, we imported the matchable interface.
And we told TypeScript very directly in this case, hey, typescript, we want our class user or an
instance of user to be compatible with the makeable interface.
So to do so, we optionally add on implements makeable right here.
And that tells TypeScript we are trying to make a user satisfied the matchable interface by adding that
in typescript is going to take a look at our user definition and make sure that we are implementing
the correct properties again, 100 percent optional.
The only reason we do this is so that we can kind of help other engineers understand what we're doing
at this class right here.
So if another engineer saw the statement, they would understand, oh, OK, I get it.
We want a user to be immoveable.
The other reason we add this in is that TypeScript can take a look at the different properties here
and help us make sure that we add in all the correct properties.
OK, so that's it, that's the three big important things here, once again, inside of index states
wanted to restrict API service area.
Second off, we wanted to use interfaces to set up a type of dependency between the different classes
inside of our application.
And then finally, we can help TypeScript put errors in the correct location by using this implements
clause on classes.
So with all this in mind, let's take a pause right here.
We're going to go to the next video and start working on our next application.