Who in this video will find the answer to the question 47?
What is coupling?
Coupling is the degree to which one module depends on another module.
In other words, it's a level of intimacy between modules if a module is very close to another, knows
a lot about its details and will be affected if the other changes.
It means they are strongly coupled.
Have you ever needed to introduce a small turnout in a class, but it actually forced you to also introduce
changes in many of our classes?
Well, it seems like those classes were strongly coupled with each other.
It made them brittle.
They got broken and needs to be fixed when that turned was introduced somewhere else.
The high or strong coupling means that one class knows too much about what is going on under the hood
of another class law, or a loose coupling is a desirable trait of classes.
This illustration shows the strong coupling between two classes.
Those classes, although separate, no way too much about each other, and they communicate directly
to reduce coupling.
We should introduce a simple, well-defined interface that will be the channel to which they communicate
this way.
If something changes in one of the classes, the other will not be affected as long as the interface
doesn't change.
And remember, the implementation details change much more frequently, then interfaces.
Let's see some strong recap of the classes.
Here is the subscriber data structure that simply holds an array of subscribers.
It is used by the newsletter center across.
This crisis responsibility is to send emails to subscribers.
Here it uses the subscribers collection.
At first glance, it may look all right.
But notice how the sender mattered and thus the whole newsletter sender class depends on implementation
details or the subscribers class.
It is not only aware that it was a very concrete type of a correction, so an hour, but it could even
modify its elements.
You've one class can make members of another class know.
It means they are way too close to each other.
Let's see what would happen if I wanted to turn the correction that the subscribers class use from an
array to set.
Now.
The Senate do matter the breaks I turned on the implementation detail in the subscriber's class, and
it shouldn't affect another classes it did, which proves that our code is brittle.
Let's fix it.
The subscriber's class should only expose an abstract collection of items that make it a innumerable.
The consumers of this class don't need to know whether it's an array, a hush set or anything else.
Now, let's adjust the code in the newsletters underclass.
Great.
Now the newsletter centre across is not aware of the implementation details of our classes as far as
it's concerned, the subscribers grass only provide a collection that can be inaugurated, whether it's
an array of East or anything else is irrelevant and content.
We founded the newsletter Standard Class, even knowing you can recognize like uplink by observing the
following one type uses another type directly without having an obstruction in between.
Even a small terms in classes leads to a cascade of tenders all around the project.
Classes are not independent to make some object work.
We need to set up some state in other objects.
This is particularly visible in interesting when setting up a test.
We must do a lot of work on other objects than the one that we actually want to test.
The question is what can we do when we observe that our code is tightly coupled?
The best solution is to simply reduce the direct connection between concrete types illustrated like
this.
Let's say I want to go for a trip by the sea.
Currently, I am tightly coupled with the car class, and they only accept it as the means of transportation.
It may mean that my weekend will be ruined if my car breaks down or, for example, my driving licence
expires.
If I would only depend on some, I mean, of transport service.
It would mean that I am not coupled with any concrete type implementing it, and I could easily switch
the car to a plane or a train.
And my weekend would be saved.
I wouldn't depend on the technical details of the means of transport.
I would only mean to be provided with something I can use to travel and what it is or how it works under
the hood.
I don't really care as long as it takes me to the beach.
We did a similar thing here instead of depending on a concrete area type.
We started to depend on the innumerable interface and we are not affected if the type implementing it,
January's from arrow to harsh.
As you can see, to reduce clapping, we should have different types communicate over interfaces, not
directly.
If you know the dependency inversion principle from the solid principles, you can see that its main
purpose is reducing copying.
According to this principle, types should not depend on concrete implementations, but rather on abstractions.
By following this principle would remove the direct way of communication between classes, making them
more independent from each other.
In other words, less coupled, the perfect classes and modules should be highly cohesive and loosely
coupled.
Let's summarize coupling is the degree to which one module depends on another module.
In other words, it's a level of intimacy between modules.
If a module is very close to another knows a lot about its details and what is going on under its hood.
And most of all, would be affected if the other changes.
It means those two modules are strongly kaput.
During the interview, you can be asked how to recognize strongly couple of drops.
If one type uses another type directly without having an obstruction in between.
We often recognize strong coupling the hard way when we see that even a small change in a class leads
to a cascade of changes around the project.
It proves that the types are not independent.
Which of the solid principles allow us to reduce coupling the dependency inversion principle, which
says that classes shouldn't depend on concrete implementations, but rather on abstractions.
When following this principle, we remove the direct way of communication between classes, making them
more independent from each other.
All right, that's it about coupling.
Thanks for watching and see you in the next video.