live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Join this live session with Stephen Simon ft. Tural Suleymani for the next episode of A Dash of .NET - live show on February 22, at 09:30 PM (PST).
This session talks about the importance of high cohesion and loosely coupling in programming. No matter what languages you're using, they are really important topics to understand
Show More Show Less View Video Transcript
0:00
Have you ever been in a situation where you changed one line of code and your entire program
0:09
stopped working? I have been there and I believe you have been there too
0:13
Today we're going to talk about a really interesting topic that is about loose coupling and talk
0:18
about this really interactive topic and something that everyone can relate. We have Tural Sulemani
0:26
I hope that's how you say his last name. He's a senior .NET developer, very active in the community, C-Sharp Content MVP
0:33
And we all love him there. So without any further ado, let's bring Tural
0:37
Hi Tural, welcome to the show. Hey Simon, thank you very much for having me
0:42
How are you doing? I'm doing absolutely great Tural. Thank you for accepting the invitation
0:46
You know, finally we get to meet you and finally the entire community gets to see how handsome
0:52
Tural is. Sounds a little bit scary. Tural, we're going to do chit-chat towards the end of this session. I'm not going to take much of time
0:56
I'll add your screen to the presentation and I'll let you take it from there. Exactly
1:11
Okay, in this session we're going to talk about loose coupling in software design
1:17
I think this is one of the important topics in software design
1:21
And for me, the software design starts from the high cohesion and loose coupling
1:26
This is my personal opinion. Why? Because when you dive into details of software design, you're actually learning the loose
1:34
coupling and high cohesion in more detail. Let's see what we have in our agenda
1:40
We'll talk about the roles of high cohesion and loose coupling in software design
1:44
And of course, we'll dive into details of loose coupling. There are a lot of forms of loose coupling, but I will mention only the most important ones. Okay
1:54
So first things first, let's try to understand first what is modularization
2:01
What is a software? A software is a problem. So there is a problem and we are trying to solve the problem using some sort of programming
2:10
language technologies. So we are building some sort of application. And we are trying to handle complexity in this application using divide and conquer principle. Okay
2:25
So we are dividing a complex software system into smaller, more manageable models with
2:31
clear tasks and boundaries. From the example of microservice, let me explain this concept
2:37
So we have this sort of microservice and microservice consists from smaller services. Okay
2:44
And these services have their own bounded context. And when we are dealing with a big problem, we are trying to divide it into smaller tasks
2:56
You can think about it like a small problem. Okay? Right now we have three small problems
3:03
And in this case, every microservice may have more than one modules
3:10
Actually, they will have a lot of submodules in there. Okay? So in this case, let's say this is our account microservice
3:19
This is our customer microservice. In customer microservice, we have 20 modules
3:24
Here we have 25 submodules. So these submodules should have tightly coupled relation between each other because they have
3:34
one single bounded context. And they have one huge reason to change
3:40
They are tightly coupled. This is the concept of high cohesion inside one module
3:48
But we need to communicate between these modules to have one single application, big application. Okay
3:57
In this case, we are trying to somehow, it doesn't matter, you're building a synchronous
4:02
communication, asynchronous communication between these microservices. At the end, we are trying to have loosely coupled communication between microservices. Why
4:13
Because we need extensibility. We need to change these modules without depending with each other. Okay
4:21
This is how we are dealing with high cohesion and loosely coupling
4:25
In general, we have these loosely coupling elements. These are forms of loosely coupling
4:32
We'll start to talk about content coupling. Then we have a lot of other coupling stuff in this presentation
4:39
I just demoed that with colors that we have these six items
4:45
And first we'll start from content coupling and we'll end with data coupling
4:49
And in the middle, we have different sort of couplings. We'll talk about it
4:54
For me, the high cohesion and loosely coupling, it looks like union symbol. Okay
5:02
You cannot create an application that is fully modular. There is no need to create fully modular application
5:10
Your application should consist from static and dynamic elements. This side, let's say our static elements, this side are our dynamic elements
5:21
So they should live together to have a big application. This is how we are dealing with complexity
5:31
If you think to deal with complexity to make fully dynamic application, this is not correct
5:39
There is no need always to have interfaces, abstract classes everywhere if you're using
5:44
C-sharp language. So your application should consist from static elements and also from the dynamic elements. Okay
5:53
And loosely coupling. Loosely coupling is about unrelated things. So in our previous scenario, there was three microservices
6:03
And these microservices by itself, they are unrelated things. Yeah, of course, from the B context, they are related with each other
6:11
But in general, they are unrelated things. For example, customer is doing with customer things, customer business operations, order
6:21
is dealing with order operations. So they are completely unrelated. It is possible for us just to grab this microservice and use in another context with other applications. Okay
6:33
So loosely coupling occurs between two models. But high cohesion is inside one model
6:41
When you are building an application, you should take into account that you should create
6:48
loosely coupled relation between elements that these elements are unrelated elements. So loosely coupling is about unrelated things that should change independently
7:02
And of course, there are tons of benefits of loosely coupling, high cohesion
7:06
Let's talk about the benefits of loosely coupling. It helps us to increase maintainability, improve reusability
7:13
From the scalability perspective, it is really good to use loosely coupling
7:18
And of course, it provides us a greater flexibility. I don't want to talk much about the theoretical stuff
7:27
You can find more information on the internet. But let's focus on the practical stuff. Okay
7:32
Let's talk about the loosely coupling, the elements of loosely coupling. First one is our content coupling
7:42
This is really important to understand. It doesn't matter if you are a junior developer, middle developer, double middle, triple middle
7:51
It actually doesn't matter if you are a software architect. You should understand this concept, the high cohesion and loosely coupling to write a better code
8:01
This is really important. So what is the content coupling? This content coupling occurs when different modules, let's say we have two modules and
8:11
we want to communicate with each other. They want to communicate with each other
8:16
We are directly referring and manipulating to the second module's internal data or implementation details
8:27
So you should encapsulate your logic and you shouldn't provide your other modules to directly
8:34
interact your module's data structure, internal data and implementation details. This is a simple example here for the content coupling
8:45
For example, some function here. Okay? And we have calculator at the class
8:50
I will show you the example from the C Sharp perspective, but if you know C Sharp, JVA
8:57
doesn't matter. They are high level language. So you should feel confident with these examples
9:03
In my case, what I'm trying to do, I'm trying to calculate first number and second number
9:09
and set result to calculator again. This is a huge problem because the responsibility of calculator is calculate, but you're another
9:21
method trying not to delegate but directly calculate and set results. So you are referring to internal data
9:33
This is our first number. Second number is our internal data. They are just properties
9:41
But you are directly referring to the result. The calculator should encapsulate the calculation logic and should not provide you to set data
9:53
like this. In this case, you should just delegate. You see, we are just delegating the responsibility to calculator and we are getting result from calculator
10:04
That's how it should be. Okay? That's how we are going to avoid this content coupling problem
10:13
And we also have in Visual Studio, we have a second example here
10:19
I've created a lot of interesting examples for you. So let me just open an example here
10:25
So this is just simple cart class. Okay? There is no business logic right now
10:32
What I am trying to do, I'm just trying to, for the cart number, I am trying to assign
10:37
some number. As you can see, this is not a valid number
10:42
But in my case, for my cart, I have getter and setter
10:48
And you may think that if you have a getter and setter, it means you are already encapsulated data
10:54
But this is not an encapsulation. And your class provides us ability to directly set invalid data
11:04
We should avoid this and we need to have additional encapsulation, additional protector
11:12
over our number, not to allow this type of data. Sorry. So this is also going to be our content coupling in this case
11:26
Okay. The second form is common coupling. We have used this common coupling everywhere when you use enums, when you are dealing with
11:37
static variables. So the common coupling refers to a specific type of tight coupling where multiple modules
11:45
within a program share access to the same global data. Of course, in .NET, we have global data concept, but it was implemented in L language
11:56
But in C sharp, we have static variables that we are going to use as a global data
12:02
Let me show you one example here. So in my case, I have, let me just close this. Okay
12:10
I have user session and this user session has the user ID
12:16
This is a static property. Okay. And my logger service is directly using this user sessions user ID
12:25
The problem here is right now I have tightly coupled between logging service and user session
12:32
This is a huge problem. When I want to change this logging sessions, it has direct dependency from user session
12:39
So it is not possible for me to change user session confidently
12:44
This is a big problem. So you need to avoid it. This is a common coupling. Okay
12:47
So you have this shared data among your modules, user session model and logging model
12:54
You need somehow to avoid it and using some sort of abstraction, using interfaces, abstract
13:02
classes, some other techniques, you can easily do it. Right now I have user ID provider as an interface and my user session inherits from a user ID provider
13:14
And in my case, logger service doesn't interact with user ID directly
13:20
I have dependency from the contract rather than implementation. And it helps me to easily change logging service
13:28
And I can easily change the implementation because I have dependency from abstract element
13:36
not the concrete element. This is how we are resolving this common coupling
13:44
Great. So the third one is going to be our external coupling
13:49
I think this is one of the interesting subtopics for loosely coupling
13:55
I will tell you one simple example here. When you are using entity framework directly in your application, it means you have external
14:03
coupling because this is a third part library. This is a different module
14:07
And your application directly depends on your entity framework. This is one of the reasons why people use a repository layer over entity framework
14:18
But entity framework by itself is also a repository with unit of work
14:22
But let's talk about external coupling. External coupling refers to the interdependence of different modules based on factors outside
14:32
the system itself. So in a simple manner, modules relying on a third-party library with no limitation
14:42
We already know that entity framework has its own limitations also. The limitation is not a fact here
14:50
So the problem here is you are depending from some third-part library
14:56
We have a lot of other examples like an application reading product data from a specific data
15:01
format, code interacting directly with specific hardware devices. So you have some sort of dependency from the implementation rather than the abstract element
15:14
In my case, let me show you one example here. This is our customer service, and my customer service depends from customer DB context
15:26
So actually, this customer DB context, as you know, inherits from DB context
15:31
DB context is my entity framework DB context. So we have direct dependency from entity framework
15:40
How you can deal with that? If you really need to isolate your application from entity framework, it doesn't mean that
15:49
if there is external coupling, it is bad. Let's try to avoid it
15:54
No, it depends. I really love the term, it depends on programming, because it really depends
16:01
In your case, the common coupling also may be okay, completely okay
16:07
So applying content coupling, common coupling, external, not content coupling, but common
16:13
external control, stamp coupling, actually depends on your applications from your requirements
16:21
In my case, I have the customer service that depends from entity framework DB context
16:28
If I want to isolate my application from entity framework, of course, I will use the
16:36
additional obstruction, like abstract classes, interfaces, et cetera, additional obstruction using repository, et cetera, to isolate my application from entity framework dependency
16:50
That's how we should deal with external coupling. Of course, not just external coupling, but it is applicable for all sorts of couplings
17:01
If you need to avoid some sort of coupling, we are always trying to add one more obstruction
17:07
over it. This is one of the way of dealing with the issue
17:14
And of course, the other one, the a little bit trick one is going to be about control coupling
17:20
It is also called tell, don't ask principle, okay? Instead of focusing on external factors, control coupling deals with how models influence
17:32
each other's execution. So you have two models, and one model dictates the flow of other model
17:39
This is a big problem. There is a boss who dictates that this model should do like this
17:46
For example, if you have EFLs, switch case type of things in your application, and one
17:52
module dictates how other models should behave. This is about our coupling also
17:59
Let's talk, let me show you one example from control coupling here
18:05
For the control coupling, I have, for example, order processor. In this case, I have two important models, order processor and order, okay
18:14
And order processor is going to be our boss, a leader. And the worker is going to be our order
18:25
And you see, we have is priority Boolean indicator, a flag. So one of the important signs of showing that there is a control coupling in your application
18:37
that it should be some sort of flag that indicates that one model manages another, okay
18:44
In my case, I have a Boolean indicator here. And depending this Boolean value, I have two type of flow for my order
18:55
It means my order is not a full functional, is not independent model
19:01
There is someone who dictates the rules. This is a big problem in our application
19:08
So how to deal with that? Of course, we have a second version here
19:12
Again, we have additional obstruction using interfaces, abstract classes, even using simple class is also obstruction
19:21
So the class is abstract data type. So it is also obstruction
19:27
In my case, we have, I order handler, okay? For order, handle order
19:34
And we have two implementations. Instead of having Boolean indicator with two flows, I have two different implementations here
19:45
And I'm injecting directly the flow itself, rather than allowing order processor to define
19:54
the path to dictate the execution path for my order. This is a little bit tricky
20:03
And the other coupling is going to be our stamp coupling. Yeah, I think we're all faced with this coupling
20:14
The problem here is, let's say you have some sort of a method, okay
20:19
And your method accepts six arguments, let's say. I don't know, four arguments, three arguments
20:26
But you are usually using only two of them, one of them
20:31
It means you have a lot of arguments, or you have one complex argument
20:36
Let's say you have a method that accepts order class as an argument
20:40
But you're using only two or three properties of this order. Instead of having another complex data or multiple small sort of arguments
20:58
you are dealing with a huge complex data, okay? The problem here is, in your case, we have two models are stamped coupled
21:08
if they communicate using a single data structure. Let me show you the example here
21:13
So in my case, we have order service. And order service has send order confirmation email
21:23
And we have customer as an argument. Problem here is, as you can see, I'm using only name
21:29
This is only a requirement for me. Instead of directly accepting string name, I'm using customer
21:35
Because it is easy for me, I don't want to spend more time just typing string name
21:43
I'm just using the customer. And I am trying to make some sort of reusable code
21:50
But there is nothing to reuse. This is a bad habit. You should provide the exact arguments you're using
21:56
So if you have two arguments, you should exactly use them. In most cases, in all .NET platform, for example, for platform invocation
22:07
or all that type of elements, you may say that there is a method that accepts 15, 16, 10 arguments
22:18
And most of them are just nulls, okay? This is also a problem of stamp coupling
22:23
You need to provide only the exact argument count that you are using
22:28
If you need to, for example, name, surname, just provide name, surname
22:32
instead of providing the customer that consists from 10, 11 properties. And how to deal with that is also obvious
22:42
We have I order confirmation data. This is one of the forms of dealing with this issue
22:48
The other one is just doing like this. Oops, let me just copy, paste
22:56
So if you are dealing with just name and surname, just provide string name and string surname
23:06
That's all. And this stamp coupling provides a way for data coupling
23:13
The stamp coupling is actually a one form of data coupling, okay
23:18
The data coupling refers to the degree of interdependence between different modules
23:23
Based on the data they exchange, it means you have the exact arguments you need to use
23:29
In my case, I did a little bit refactoring here, and now I have exact coupling called data coupling, okay
23:41
That's how we are dealing with this problem. As I mentioned, it's really important
23:46
It doesn't matter if you are going to be a software architect
23:52
or if you want to be a senior engineer, you should start to learn the basics
23:58
For me, this is also basics of software development. This is, of course, related to software design
24:08
but this is a basics of software development. So every developer, if you are a junior developer, middle developer, senior, it doesn't matter
24:16
We are using these elements in our daily basis. So you should know the loosely coupling and high equation principles
24:26
And thank you for watching. That's all about this session. Well, that was great, Dhruv
24:35
Thank you so much. I believe you talked so much about loose coupling. I never knew it so much existed
24:41
And I would encourage everyone to go ahead and check the video description
24:45
You'll find Dhruv's all social handles. And also, he has recently published a new Udemy course
24:51
You should also go and check out. You'll find all the details on his LinkedIn
24:55
Thank you so much, Dhruv. Thank you so much for this great session. And thank you so much, everyone, for watching
25:00
We will see you in the next episode of Dashboard.net. See you. Bye-bye
#Programming
#Windows & .NET