The Essence of Coupling and Cohesion in Two Minutes
Vlad Khononov
O'Reilly and Pearson Author, Keynote Speaker, Author of "Balancing Coupling in Software Design" and "Learning Domain-Driven Design"
When you couple two components, they need to share some form of knowledge: public interfaces, functional behavior, implementation details, or other types of information. Let’s call it the integration strength. The more knowledge is shared, the stronger the integration. The stronger the integration, the more both components will have to change together. Therefore, you should always look to minimize the integration strength. That said, minimizing integration strength isn’t always possible—sometimes, extensive shared knowledge is necessary. For example, when the components implement closely related business functionalities.
Another important property of integrated components is the distance between them. For example, objects in a module are located closer to each other than the source code of two microservices. The greater the distance, the higher the induced cognitive load and coordination challenges, and the more effort is needed to change the integrated components simultaneously.
Now let’s examine four extreme combinations of the two dimensions:
Low integration strength, high distance: High effort is needed to change the components simultaneously. On the other hand, the low integration strength minimizes the chances of such cascading changes. That’s loose coupling.
High integration strength, low distance: The components will have to co-evolve frequently because of the high knowledge they share. On the other hand, changing them simultaneously won’t require too much effort because of the low distance. We call this high cohesion.
Recommended by LinkedIn
High integration strength, high distance: Lots of cascading changes because of the high integration strength, and lots of effort is needed to take care of them. That’s tight coupling, and it’s no fun.
Low integration strength, low distance: In this scenario, the effort to make changes is low, but since the components don’t share much knowledge, cascading changes are rare. Unrelated components are packaged together, or in other words, that’s low cohesion.
As you can see, both coupling and cohesion are driven by the same underlying phenomena: the knowledge components share and the distance between them. That’s the essence. If you understand one, you also understand the other. That’s why in my new book Balancing Coupling in Software Design I limited the discussion of cohesion and instead focused on modularity, complexity, and the underlying dimensions of coupling: integration strength, distance, and volatility.
If you want to learn more about the levels and degrees of integration strength, technical and social factors affecting distance, and how volatility can trespass components’ boundaries—Balancing Coupling in Software Design is available in both print and digital formats on Amazon, InformIT, and other major bookstores:
Amazon: https://amzn.to/3BIIPyk
I help financial services companies beat their competitors with technology.
2moNice post! I’ve always considered coupling and cohesion to be independent so I’ll have to think a bit on your use here. In my own experience, cohesion means that things belong together by virtue of the fact that they tend to change at the same time for the same reasons. And most often cohesion refers only to the contents of some container: a class, module, or component. Coupling on the other hand can relate to things that are packaged together (low distance) or not (high distance), and whether it is tight or loose is a function of how easily replaced a dependency is (which itself is generally a function of how much knowledge is shared). Anyway, like I said, an interesting read, thanks!
Software Engineering Consultant
2moMy problem with Cohesion/Coupling definitions is that those are "static" terms. Yeah, lets define them, and then what? The processes are dynamic and non-equal. "Coupling" omits the fact that the relation is _directional_. One _depends_ or _needs_ another. This is the core meaning. Imagine Goldratt's logical trees would have no directional arrows? :=/
Just making better things
2moNice! Another 2x2 matrix that could go viral!
Solutions Architect at Flowbird
2mocircular reasoning, x & y := f(k)