Today you'll learn how keeping your abstractions more cohesive and less coupled can improve the quality and maintainability of your software.
Transcript
Coupling and Cohesion
00:00:02 - 00:05:01
welcome to the programming podcast. Here you can learn about computers in the brief and accessible way. I'm your host mean could get lower end. Today's episode of the PODCAST. We discussed two councils which are related to source code means beauty. We are going to discuss cap link and cohesion. Let's first start with cohesion. Why should we care about this? Well basically the Caucasian of a certain module. When on Komo jewel in general mean a unit of Colt? It could be a package or an script MODU or a class or even a function so the coupling of such units is the degree which determines how the elements inside of this unit belonged together. This means that if a unit has a very strong Caucasian it has a very well defined responsibility it is not going to do a variety of things which are unrelated to each other and we need to discuss a particular example just in little bits. What about Catholic? So the captain on the other side depends how the modules in the system relate to each other again by module. Simon chose different units. They could be classes or backpage is or even functions. It doesn't really matter both of these concepts. Sap mentioned are relates to source. Colts mean to beat so even though most systems in the wild are very complicated. If we have these concepts of Caucasian and Kaplan in mind we can do it. More future processes where individual modules are really cohesive really easier to reuse for example and nothing is too tangled in capital together where we have undefined number of connections between the individual abstractions and when we touch one of them would have to touch older dependent once. Because we don't know which one is being to produce unwanted effect so let's focus on quesion in general in software engineering. We're trying to increase the casual of individual units. So we have a module. We want us to be very. We want us to do only a single thing which makes also the system easier to understand right if we have a very well defined responsibilities of a certain module and we have a good name for it. This means that we really don't need to dig into the details into the implementation details of this module we can just look at the name and we're going to be completely certain who was this module is all about. Let me give you an example on engineering example. On what does it mean to have a cohesive design so a couple of episodes back I the decorator potter and there? I explain to you. How e communication channel in the PLATFORM RHYME DOT COM this communication channel? I was able to decorate inner to provides a way to add extra functionality to do it for example requests response or different types of notifications and so on and so forth but all of the messages. That's our exchange in this message channel in this communication channel. They have their own for that. And in some cases for some for some systems we may want to change this format for example only very band sensitive systems where the user has very limited bandwidth we may want to just send a binary the messages in binary format because this has to be much more compressed format that's going to consume that much network in error platforms however on other systems. We may want to call the message. Jason Format and this might be absolutely reasonable decision because the messages are much easier to reason about their human readable format pretty much whilst we as the necessary amount of spaces and it intention. So that's another completely reasonable encoding. Kim For your messages and the question is should we put the formatting logic inside of the message channel or not? Well probably the right answer. This question is going to be that we should extract the message for matting logical the messaging causing logic into a separate abstraction this way our message channel is going to be only responsible for connecting to the other party for receiving and sending messages as eventually disconnecting from the other side. If we want to update the message formats we can just take the color implementation impacted down as a dependence of the message channel.
00:05:02 - 00:10:05
And that's if we want to change the message format we can just bess. Different call credit. See how easy it is. So these are two very obstructions. We have the mass channel which has good level of casual and we also have the clinic. Which only being called decoding messages. There is a very interesting paper which is called Caucasian entry using object oriented systems which shows that inheritance like very aggressive inheritance of Cohen obstructions can lead to poor cohesion and this is actually an excellent prove that we shouldn't aim for very aggressive. Harrington's pretty much nowhere because inheritance Keppel's our classes. I L look like inheritances. I guess. The strongest level of helping the chief because inherit all the public and protected methods from your parent and on top of that whilst we aim to reels give an obstruction in different inheritance. Chains is very unlikely that we add some unrelated things. Some things up definitely don't fit all individual use cases and all the different contexts in which we're trying to use the space class right in the last part of the podcast would want us to briefly discuss Catholic. So Losing Kaplan is usually a good thing. This means that if we have a single obstruction and it knows for fewer other abstractions as cool in the system. This is probably going to be fine. You mentioned we have and different classes in our system and each one of these classes knows about all the other end minus one glasses. Well in this case if we change one of the clauses in the systems we may have some unwanted effects on the other classes as well so this creates a very UN maintainable system. We're going to capital one of our classes to own other classes. Which means that. Well if we update the public interface to any of these classes will have to update all of its dependencies as well. So that's definitely not ideal. There is also a really interesting paper. I have linked into resources for episode which discusses how coupling can impact the systems Maine's ability they're looking at existing projects had how many defects they have and they're trying to figure out some quality metrics counseling. That can help you have a better heuristic own. What effect the capping system can have on your productivity. There are different types of couplings. Well the one that I mentioned where one class is coupled to many other classes public. Interfaces this is just only one of the main examples. We have temporal Catholic. As well for example we have side effects many functions side effects and we have a global state. The result of the location of the individual functions could be dependent on the order in which we get involved because each one of them can produce mutations that are later being consumed by the outer functions and we may have unpredictable system this way so temporal. Kathleen is something that you should probably think about this. Well when you're writing your skills so there is very interesting. War of the mutual debts. You can read more about. I have applied a link in the resources for today's episode. It's pretty sensible. Some constraints on top of the methods and properties that you can access inside of the methods of surgeon glasses so this war is really very powerful at the same time as most walls has its own exceptions. So you shouldn't always probably one hundred percent of the time especially if you're putting performance critical system because it leads to the creation of some rappers in direction which can slow down eventually Your performance to some extent quietly. I just walked to share a couple of words about also Kaplan and aiming at this far to address you mentioned you have a system which has a couple of completely independent modules that are communicating through a publisher. Describe or a message. Bus Each of these modules. They subscribe to a certain topic. And they only communicate via this message bus so none of the modules or none of the objects you can think about these obstructions as objects or functions or even gala packages or however. You prefer to all of them. They just know a little bit of the interface of the publish subscribe or of the message bus obstruction. They don't know anything about each other. Although at first the system seems great individual modules.
00:10:05 - 00:11:23
They have really strong cohesion and they have minimum amount of Catholic. Well at the same time. They're really hard to reason about at some points. You may need to have really complicated. Interactions across these modules and they might be really hard to be tested in Isration. It might be really hard to track. What kind of messages are exchanged between all these different objects? You may have even Surkov dependencies? That are extremely hard to track. Because this system relies entirely on this dynamic linking between these modules exchanging messages that are completely undefined. At bill time this means that although we should be aiming to lose Kaplan can our system coupling stoop helps with communication is to help us to know which particular abstractions depend on other obstructions all right. Let's discuss caffeine can cohesion? I really hope that you'll be able to extract some value out of it and be able to build more maintainable and structural systems. Thank you learn about the. He can follow me on. Twitter at Ham. Resources and recordings is available at Podcast Dot M. Dot com thanks listening.