1
00:00:07,230 --> 00:00:12,360
Who in this video will find the answer to the question 47?

2
00:00:12,690 --> 00:00:14,190
What is coupling?

3
00:00:14,820 --> 00:00:20,040
Coupling is the degree to which one module depends on another module.

4
00:00:20,400 --> 00:00:28,830
In other words, it's a level of intimacy between modules if a module is very close to another, knows

5
00:00:28,830 --> 00:00:33,770
a lot about its details and will be affected if the other changes.

6
00:00:33,900 --> 00:00:36,240
It means they are strongly coupled.

7
00:00:36,780 --> 00:00:43,770
Have you ever needed to introduce a small turnout in a class, but it actually forced you to also introduce

8
00:00:43,770 --> 00:00:45,990
changes in many of our classes?

9
00:00:46,350 --> 00:00:50,970
Well, it seems like those classes were strongly coupled with each other.

10
00:00:51,300 --> 00:00:52,770
It made them brittle.

11
00:00:53,130 --> 00:00:58,980
They got broken and needs to be fixed when that turned was introduced somewhere else.

12
00:00:59,460 --> 00:01:07,170
The high or strong coupling means that one class knows too much about what is going on under the hood

13
00:01:07,200 --> 00:01:13,470
of another class law, or a loose coupling is a desirable trait of classes.

14
00:01:14,040 --> 00:01:18,660
This illustration shows the strong coupling between two classes.

15
00:01:19,110 --> 00:01:26,370
Those classes, although separate, no way too much about each other, and they communicate directly

16
00:01:26,970 --> 00:01:28,210
to reduce coupling.

17
00:01:28,260 --> 00:01:35,040
We should introduce a simple, well-defined interface that will be the channel to which they communicate

18
00:01:35,370 --> 00:01:36,140
this way.

19
00:01:36,150 --> 00:01:43,140
If something changes in one of the classes, the other will not be affected as long as the interface

20
00:01:43,140 --> 00:01:44,100
doesn't change.

21
00:01:44,400 --> 00:01:50,340
And remember, the implementation details change much more frequently, then interfaces.

22
00:01:51,000 --> 00:01:53,600
Let's see some strong recap of the classes.

23
00:01:54,630 --> 00:02:00,540
Here is the subscriber data structure that simply holds an array of subscribers.

24
00:02:00,840 --> 00:02:03,750
It is used by the newsletter center across.

25
00:02:05,790 --> 00:02:10,380
This crisis responsibility is to send emails to subscribers.

26
00:02:10,980 --> 00:02:13,650
Here it uses the subscribers collection.

27
00:02:14,250 --> 00:02:16,680
At first glance, it may look all right.

28
00:02:16,980 --> 00:02:24,600
But notice how the sender mattered and thus the whole newsletter sender class depends on implementation

29
00:02:24,600 --> 00:02:26,850
details or the subscribers class.

30
00:02:27,330 --> 00:02:34,500
It is not only aware that it was a very concrete type of a correction, so an hour, but it could even

31
00:02:34,620 --> 00:02:36,300
modify its elements.

32
00:02:41,440 --> 00:02:44,980
You've one class can make members of another class know.

33
00:02:45,160 --> 00:02:48,240
It means they are way too close to each other.

34
00:02:51,390 --> 00:02:58,140
Let's see what would happen if I wanted to turn the correction that the subscribers class use from an

35
00:02:58,140 --> 00:02:59,790
array to set.

36
00:03:04,090 --> 00:03:04,750
Now.

37
00:03:06,060 --> 00:03:12,570
The Senate do matter the breaks I turned on the implementation detail in the subscriber's class, and

38
00:03:12,570 --> 00:03:19,050
it shouldn't affect another classes it did, which proves that our code is brittle.

39
00:03:19,560 --> 00:03:20,640
Let's fix it.

40
00:03:21,000 --> 00:03:28,620
The subscriber's class should only expose an abstract collection of items that make it a innumerable.

41
00:03:29,370 --> 00:03:36,510
The consumers of this class don't need to know whether it's an array, a hush set or anything else.

42
00:03:51,530 --> 00:03:55,490
Now, let's adjust the code in the newsletters underclass.

43
00:04:12,420 --> 00:04:12,800
Great.

44
00:04:13,470 --> 00:04:21,300
Now the newsletter centre across is not aware of the implementation details of our classes as far as

45
00:04:21,300 --> 00:04:27,930
it's concerned, the subscribers grass only provide a collection that can be inaugurated, whether it's

46
00:04:27,930 --> 00:04:33,030
an array of East or anything else is irrelevant and content.

47
00:04:33,090 --> 00:04:40,170
We founded the newsletter Standard Class, even knowing you can recognize like uplink by observing the

48
00:04:40,170 --> 00:04:46,980
following one type uses another type directly without having an obstruction in between.

49
00:04:47,490 --> 00:04:53,550
Even a small terms in classes leads to a cascade of tenders all around the project.

50
00:04:54,000 --> 00:04:58,070
Classes are not independent to make some object work.

51
00:04:58,110 --> 00:05:01,440
We need to set up some state in other objects.

52
00:05:01,920 --> 00:05:07,090
This is particularly visible in interesting when setting up a test.

53
00:05:07,110 --> 00:05:13,080
We must do a lot of work on other objects than the one that we actually want to test.

54
00:05:13,590 --> 00:05:19,440
The question is what can we do when we observe that our code is tightly coupled?

55
00:05:19,680 --> 00:05:27,840
The best solution is to simply reduce the direct connection between concrete types illustrated like

56
00:05:27,840 --> 00:05:28,320
this.

57
00:05:28,830 --> 00:05:31,950
Let's say I want to go for a trip by the sea.

58
00:05:32,500 --> 00:05:39,570
Currently, I am tightly coupled with the car class, and they only accept it as the means of transportation.

59
00:05:39,960 --> 00:05:47,700
It may mean that my weekend will be ruined if my car breaks down or, for example, my driving licence

60
00:05:47,700 --> 00:05:48,570
expires.

61
00:05:49,020 --> 00:05:53,130
If I would only depend on some, I mean, of transport service.

62
00:05:53,340 --> 00:05:59,870
It would mean that I am not coupled with any concrete type implementing it, and I could easily switch

63
00:05:59,880 --> 00:06:02,400
the car to a plane or a train.

64
00:06:02,640 --> 00:06:04,680
And my weekend would be saved.

65
00:06:05,010 --> 00:06:09,060
I wouldn't depend on the technical details of the means of transport.

66
00:06:09,300 --> 00:06:16,470
I would only mean to be provided with something I can use to travel and what it is or how it works under

67
00:06:16,470 --> 00:06:17,100
the hood.

68
00:06:17,220 --> 00:06:20,880
I don't really care as long as it takes me to the beach.

69
00:06:21,510 --> 00:06:27,270
We did a similar thing here instead of depending on a concrete area type.

70
00:06:27,600 --> 00:06:34,560
We started to depend on the innumerable interface and we are not affected if the type implementing it,

71
00:06:34,770 --> 00:06:36,660
January's from arrow to harsh.

72
00:06:37,680 --> 00:06:44,160
As you can see, to reduce clapping, we should have different types communicate over interfaces, not

73
00:06:44,160 --> 00:06:44,880
directly.

74
00:06:45,420 --> 00:06:51,930
If you know the dependency inversion principle from the solid principles, you can see that its main

75
00:06:51,930 --> 00:06:54,030
purpose is reducing copying.

76
00:06:54,540 --> 00:07:01,740
According to this principle, types should not depend on concrete implementations, but rather on abstractions.

77
00:07:02,340 --> 00:07:09,600
By following this principle would remove the direct way of communication between classes, making them

78
00:07:09,600 --> 00:07:11,790
more independent from each other.

79
00:07:12,210 --> 00:07:20,100
In other words, less coupled, the perfect classes and modules should be highly cohesive and loosely

80
00:07:20,100 --> 00:07:20,790
coupled.

81
00:07:21,390 --> 00:07:27,870
Let's summarize coupling is the degree to which one module depends on another module.

82
00:07:28,380 --> 00:07:32,580
In other words, it's a level of intimacy between modules.

83
00:07:32,970 --> 00:07:40,290
If a module is very close to another knows a lot about its details and what is going on under its hood.

84
00:07:40,620 --> 00:07:44,010
And most of all, would be affected if the other changes.

85
00:07:44,160 --> 00:07:47,160
It means those two modules are strongly kaput.

86
00:07:47,790 --> 00:07:53,100
During the interview, you can be asked how to recognize strongly couple of drops.

87
00:07:53,640 --> 00:07:59,370
If one type uses another type directly without having an obstruction in between.

88
00:07:59,760 --> 00:08:06,870
We often recognize strong coupling the hard way when we see that even a small change in a class leads

89
00:08:06,900 --> 00:08:10,080
to a cascade of changes around the project.

90
00:08:10,470 --> 00:08:13,800
It proves that the types are not independent.

91
00:08:14,550 --> 00:08:22,080
Which of the solid principles allow us to reduce coupling the dependency inversion principle, which

92
00:08:22,080 --> 00:08:28,290
says that classes shouldn't depend on concrete implementations, but rather on abstractions.

93
00:08:28,770 --> 00:08:35,610
When following this principle, we remove the direct way of communication between classes, making them

94
00:08:35,610 --> 00:08:37,740
more independent from each other.

95
00:08:38,340 --> 00:08:40,860
All right, that's it about coupling.

96
00:08:41,310 --> 00:08:44,370
Thanks for watching and see you in the next video.