1
00:00:07,260 --> 00:00:15,260
So with this lecture, we start to talk about questions related to cold quality and design patterns.

2
00:00:15,750 --> 00:00:20,310
We'll begin with Question 46 What is cohesion?

3
00:00:20,760 --> 00:00:26,640
Cohesion is the degree to which elements of a module or across belong together.

4
00:00:27,000 --> 00:00:34,620
In simpler words, it measures how strong the relationship is between members of this module or across.

5
00:00:35,130 --> 00:00:41,640
The closer the relationship is, the better how cohesion is a desirable trait.

6
00:00:42,240 --> 00:00:45,570
Let's see how high cohesion could be illustrated.

7
00:00:46,500 --> 00:00:50,010
This is a highly cohesive class or a module.

8
00:00:50,550 --> 00:00:53,970
As you can see, no piece seems to be lonely.

9
00:00:54,480 --> 00:01:00,780
There is a lot of connections between them, and it would be hard to draw a line in which this module

10
00:01:00,810 --> 00:01:01,740
could be split.

11
00:01:02,310 --> 00:01:05,310
Now, let's see a module that is not cohesive.

12
00:01:06,240 --> 00:01:12,660
In this case, there are some pieces that seem to have very little or nothing to do with others.

13
00:01:13,170 --> 00:01:18,690
We can easily see how this module could be divided into highly cohesive modules.

14
00:01:19,770 --> 00:01:24,510
As you can see, I've kept the connection between the green and red parts.

15
00:01:24,870 --> 00:01:28,470
But I made it go through some abstraction in C sharp.

16
00:01:28,500 --> 00:01:30,840
This would most likely be an interface.

17
00:01:31,410 --> 00:01:32,910
Let's see some code now.

18
00:01:34,090 --> 00:01:37,240
This glass is characterized by high cohesion.

19
00:01:37,720 --> 00:01:41,860
All those methods use the underlying collection called parts.

20
00:01:42,160 --> 00:01:47,200
The contains method uses the get currency startup's method.

21
00:01:47,830 --> 00:01:51,850
None of those methods could be easily moved away from this glass.

22
00:01:52,240 --> 00:01:58,510
There is no easy way to split this glass into separate classes, nor it would make much sense as those

23
00:01:58,510 --> 00:02:00,970
methods naturally belong to Lever.

24
00:02:01,480 --> 00:02:04,180
Now, let's consider a different class.

25
00:02:06,100 --> 00:02:07,720
Let's see what it does.

26
00:02:08,200 --> 00:02:10,120
It has two public methods.

27
00:02:10,690 --> 00:02:17,590
First, one accepts the house object as a parameter, and it calculates price for it, depending on

28
00:02:17,590 --> 00:02:21,040
the area and the number of floors in the house.

29
00:02:21,610 --> 00:02:29,410
The second method sends the price to an owner, finding his or her email by address using the owners

30
00:02:29,410 --> 00:02:30,280
database.

31
00:02:31,060 --> 00:02:32,920
This class is not cohesive.

32
00:02:33,220 --> 00:02:36,310
It goes to quite separate responsibilities.

33
00:02:36,730 --> 00:02:42,490
First one is evaluating the price of the house and second is notifying the owner.

34
00:02:43,030 --> 00:02:50,170
The only point where those two responsibilities meet is that the send price to owner method needs the

35
00:02:50,170 --> 00:02:52,070
information about the price.

36
00:02:52,420 --> 00:02:55,250
But this is something that can be easily refactor.

37
00:02:56,280 --> 00:03:01,030
That's refactoring this class by creating two highly cohesive classes.

38
00:03:24,050 --> 00:03:30,890
I created the owner notifier class, and I moved here the methods we like to push notifications.

39
00:03:31,430 --> 00:03:36,110
The problem is here because the gate price method doesn't belong here.

40
00:03:36,620 --> 00:03:43,280
I think it's a good idea to make this method more generic, so it concerned any type of information.

41
00:03:43,490 --> 00:03:45,620
Not only the price of the house.

42
00:03:54,560 --> 00:04:02,210
Right now, this class is cohesive, and it's highly focused on the responsibility of sending some information

43
00:04:02,210 --> 00:04:08,810
to some owner and also the house price or class is also highly cohesive.

44
00:04:09,140 --> 00:04:15,200
The only thing it does now is what its name suggests getting the price of a house.

45
00:04:15,770 --> 00:04:19,760
Now we can simply use those classes one after another.

46
00:04:44,140 --> 00:04:46,930
Actually, this name is no longer accurate.

47
00:04:47,410 --> 00:04:49,570
Let's rename it to something more generic.

48
00:05:01,530 --> 00:05:02,250
All right.

49
00:05:02,730 --> 00:05:09,270
As you can see, splitting the original cross into two highly cohesive classes was quite simple.

50
00:05:09,900 --> 00:05:17,730
By now, you may probably be thinking, Oh, so high cohesion and single responsibility principle are

51
00:05:17,730 --> 00:05:18,780
the same things.

52
00:05:19,260 --> 00:05:27,210
Well, no, but it's common that highly cohesive class meets the single responsibility principle and

53
00:05:27,210 --> 00:05:28,140
vice versa.

54
00:05:29,070 --> 00:05:36,210
High cohesion means that the data and methods that belong together are kept together.

55
00:05:36,600 --> 00:05:41,310
If following only the single responsibility principle, we could.

56
00:05:41,490 --> 00:05:49,260
But it doesn't mean we should keep splitting classes into smaller and smaller pieces until every class

57
00:05:49,380 --> 00:05:51,570
would have only one public method.

58
00:05:51,990 --> 00:05:58,530
Each of those tiny classes would definitely meet the single responsibility principle, as they would

59
00:05:58,530 --> 00:06:03,240
only have a single responsibility and a single reason to change.

60
00:06:03,630 --> 00:06:08,010
But they wouldn't be cohesive as those methods should belong together.

61
00:06:08,490 --> 00:06:12,990
So should we keep splitting the classes into smaller and smaller pieces?

62
00:06:13,500 --> 00:06:16,380
Well, no, at least not always.

63
00:06:16,830 --> 00:06:24,510
Imagine what would happen if the last class was split into tiny classes like least other, which is

64
00:06:24,510 --> 00:06:31,620
adding something to the list least remove our which is removing something least clever, least gold

65
00:06:31,620 --> 00:06:39,210
getter, etc. That would be unmentionable and hard to understand, and no one would like to use those

66
00:06:39,210 --> 00:06:39,930
classes.

67
00:06:40,500 --> 00:06:48,100
Now all those methods add, remove clear, and the current property belong to a highly cohesive list

68
00:06:48,120 --> 00:06:48,660
class.

69
00:06:49,140 --> 00:06:56,310
This class is foreclosed on, providing a generic dynamic collection, and this is its responsibility.

70
00:06:56,760 --> 00:07:02,490
It still meets the single responsibility principle because it has one reason to change.

71
00:07:02,790 --> 00:07:09,510
It will change if the idea of how such a collection structure should be represented in such a generous

72
00:07:10,230 --> 00:07:17,580
high cohesion is not something we should create is something we observe, and our job is not to break

73
00:07:17,580 --> 00:07:20,280
it in highly cohesive classes.

74
00:07:20,580 --> 00:07:26,500
Most or all members use the same private data, and they reuse member methods.

75
00:07:27,120 --> 00:07:30,150
The functionalities of a class have much in common.

76
00:07:30,570 --> 00:07:38,160
The class would be hard to split if we did it out of private data would need to be passed from one part

77
00:07:38,160 --> 00:07:39,000
to another.

78
00:07:39,390 --> 00:07:43,390
The class is easier to name and its name is accurate.

79
00:07:44,010 --> 00:07:46,700
In class, it is characterized by a local region.

80
00:07:47,160 --> 00:07:51,510
Some private members are used by a specific group of members only.

81
00:07:51,810 --> 00:07:54,930
Other members are used by a different group.

82
00:07:55,410 --> 00:07:58,230
The functionalities of a class are unrelated.

83
00:07:58,710 --> 00:08:04,320
The class is easy to split, and the line of splitting is not real and obvious.

84
00:08:04,710 --> 00:08:09,660
Class is hard to name precisely, or its name lies about what it does.

85
00:08:10,260 --> 00:08:11,940
If you see how cohesion.

86
00:08:12,270 --> 00:08:13,230
Don't break it.

87
00:08:13,500 --> 00:08:16,230
High cohesion gives us a lot of benefits.

88
00:08:16,710 --> 00:08:20,880
Highly cohesive classes are easier to understand and use.

89
00:08:21,450 --> 00:08:28,350
They provide a highly focused set of operations instead of more functionality than we need.

90
00:08:28,920 --> 00:08:32,280
Think about the owner notifier class that we created.

91
00:08:32,790 --> 00:08:39,090
It could easily be reused to send some other information to the person living at some address.

92
00:08:39,780 --> 00:08:46,290
When a change is needed, it's easier to introduce as it affects fewer modules or classes.

93
00:08:46,830 --> 00:08:51,540
Cohesive classes are easy to test, and they are reusable.

94
00:08:52,290 --> 00:08:59,670
When you see a class that is not highly cohesive, consider refactoring it and splitting it into highly

95
00:08:59,670 --> 00:09:00,810
cohesive pieces.

96
00:09:01,590 --> 00:09:02,700
Let's summarize.

97
00:09:03,000 --> 00:09:08,520
Cohesion is the degree to which elements of a module or class belong together.

98
00:09:09,090 --> 00:09:14,670
It measures how strong the relationship is between the members of this module or our class.

99
00:09:15,060 --> 00:09:18,420
High cohesion is something we want in our code.

100
00:09:18,900 --> 00:09:26,460
During the interview, you can hear a question that is a little bit tricky is following the single responsibility

101
00:09:26,460 --> 00:09:30,420
principle and keeping high cohesion the same thing?

102
00:09:31,050 --> 00:09:38,280
No, but it's common that the highly cohesive class meets the single responsibility principle and vice

103
00:09:38,280 --> 00:09:38,940
versa.

104
00:09:39,570 --> 00:09:47,280
High cohesion means that the data and methods that belong together are grouped together if following

105
00:09:47,310 --> 00:09:50,310
only the single responsibility principle.

106
00:09:50,520 --> 00:09:57,750
We could, but it doesn't mean we should keep splitting classes into smaller and smaller pieces until

107
00:09:57,750 --> 00:10:00,630
every class would have only one public method.

108
00:10:01,240 --> 00:10:08,050
Those classes would meet the single responsibility principle, but they wouldn't be cohesive as those

109
00:10:08,050 --> 00:10:10,300
matters should belong together.

110
00:10:11,080 --> 00:10:11,860
All right.

111
00:10:12,280 --> 00:10:13,690
That's it in this video.

112
00:10:14,140 --> 00:10:15,590
Thanks for following along.

113
00:10:15,610 --> 00:10:17,380
And see you in the next one.