So with this lecture, we start to talk about questions related to cold quality and design patterns.
We'll begin with Question 46 What is cohesion?
Cohesion is the degree to which elements of a module or across belong together.
In simpler words, it measures how strong the relationship is between members of this module or across.
The closer the relationship is, the better how cohesion is a desirable trait.
Let's see how high cohesion could be illustrated.
This is a highly cohesive class or a module.
As you can see, no piece seems to be lonely.
There is a lot of connections between them, and it would be hard to draw a line in which this module
could be split.
Now, let's see a module that is not cohesive.
In this case, there are some pieces that seem to have very little or nothing to do with others.
We can easily see how this module could be divided into highly cohesive modules.
As you can see, I've kept the connection between the green and red parts.
But I made it go through some abstraction in C sharp.
This would most likely be an interface.
Let's see some code now.
This glass is characterized by high cohesion.
All those methods use the underlying collection called parts.
The contains method uses the get currency startup's method.
None of those methods could be easily moved away from this glass.
There is no easy way to split this glass into separate classes, nor it would make much sense as those
methods naturally belong to Lever.
Now, let's consider a different class.
Let's see what it does.
It has two public methods.
First, one accepts the house object as a parameter, and it calculates price for it, depending on
the area and the number of floors in the house.
The second method sends the price to an owner, finding his or her email by address using the owners
database.
This class is not cohesive.
It goes to quite separate responsibilities.
First one is evaluating the price of the house and second is notifying the owner.
The only point where those two responsibilities meet is that the send price to owner method needs the
information about the price.
But this is something that can be easily refactor.
That's refactoring this class by creating two highly cohesive classes.
I created the owner notifier class, and I moved here the methods we like to push notifications.
The problem is here because the gate price method doesn't belong here.
I think it's a good idea to make this method more generic, so it concerned any type of information.
Not only the price of the house.
Right now, this class is cohesive, and it's highly focused on the responsibility of sending some information
to some owner and also the house price or class is also highly cohesive.
The only thing it does now is what its name suggests getting the price of a house.
Now we can simply use those classes one after another.
Actually, this name is no longer accurate.
Let's rename it to something more generic.
All right.
As you can see, splitting the original cross into two highly cohesive classes was quite simple.
By now, you may probably be thinking, Oh, so high cohesion and single responsibility principle are
the same things.
Well, no, but it's common that highly cohesive class meets the single responsibility principle and
vice versa.
High cohesion means that the data and methods that belong together are kept together.
If following only the single responsibility principle, we could.
But it doesn't mean we should keep splitting classes into smaller and smaller pieces until every class
would have only one public method.
Each of those tiny classes would definitely meet the single responsibility principle, as they would
only have a single responsibility and a single reason to change.
But they wouldn't be cohesive as those methods should belong together.
So should we keep splitting the classes into smaller and smaller pieces?
Well, no, at least not always.
Imagine what would happen if the last class was split into tiny classes like least other, which is
adding something to the list least remove our which is removing something least clever, least gold
getter, etc. That would be unmentionable and hard to understand, and no one would like to use those
classes.
Now all those methods add, remove clear, and the current property belong to a highly cohesive list
class.
This class is foreclosed on, providing a generic dynamic collection, and this is its responsibility.
It still meets the single responsibility principle because it has one reason to change.
It will change if the idea of how such a collection structure should be represented in such a generous
high cohesion is not something we should create is something we observe, and our job is not to break
it in highly cohesive classes.
Most or all members use the same private data, and they reuse member methods.
The functionalities of a class have much in common.
The class would be hard to split if we did it out of private data would need to be passed from one part
to another.
The class is easier to name and its name is accurate.
In class, it is characterized by a local region.
Some private members are used by a specific group of members only.
Other members are used by a different group.
The functionalities of a class are unrelated.
The class is easy to split, and the line of splitting is not real and obvious.
Class is hard to name precisely, or its name lies about what it does.
If you see how cohesion.
Don't break it.
High cohesion gives us a lot of benefits.
Highly cohesive classes are easier to understand and use.
They provide a highly focused set of operations instead of more functionality than we need.
Think about the owner notifier class that we created.
It could easily be reused to send some other information to the person living at some address.
When a change is needed, it's easier to introduce as it affects fewer modules or classes.
Cohesive classes are easy to test, and they are reusable.
When you see a class that is not highly cohesive, consider refactoring it and splitting it into highly
cohesive pieces.
Let's summarize.
Cohesion is the degree to which elements of a module or class belong together.
It measures how strong the relationship is between the members of this module or our class.
High cohesion is something we want in our code.
During the interview, you can hear a question that is a little bit tricky is following the single responsibility
principle and keeping high cohesion the same thing?
No, but it's common that the highly cohesive class meets the single responsibility principle and vice
versa.
High cohesion means that the data and methods that belong together are grouped together if following
only the single responsibility principle.
We could, but it doesn't mean we should keep splitting classes into smaller and smaller pieces until
every class would have only one public method.
Those classes would meet the single responsibility principle, but they wouldn't be cohesive as those
matters should belong together.
All right.
That's it in this video.
Thanks for following along.
And see you in the next one.