Does cohesion really reduce coupling?

Question

'Cohesive classes reduce coupling'

So, if cohesive classes or connected classes reduce coupling (union), which piece of the puzzle is missing me?

BTW, I took this sentence from an article about identifying classes before any developmemt, which I'm trying to figure out the whole sense of why, when, how to use 'that' particular classes, polymorphism, abstraction, etc.

For sure I'm in the beginner stage about OOD. I have read some books but I don't understand the relationship between cohesion and coupling.

Answer 1

It is not contradictory; it's actually a pretty basic idea in OOD. Most of OOD principles relate to one another.

Cohesion relates to how well a given functionality is modeled in a system; if that functionality is only implemented in a single module, then that module is highly cohesive. On the other hand, if a certain functionality is scattered among many modules, then those modules have a weak cohesion. As a concrete example on measuring the cohesion of a class, consider a maximum cohesive class one that uses all its instance fields in all the methods. However in practice this is not always achievable nor desirable.

Coupling derives from how many interconnections are between modules and how strong those interconnections are. If modules heavily rely on one another then a change in a module leads to change in multiple modules.

As a relation between them if a functionality is represented by multiple modules (cohesion) then those modules are tightly coupled in order to achieve that functionality. This also relates to Single Responsibility Principle (and many other principles) which states that only one modules should have only one reason to change, leading to the idea that one module should have one functionality.

As OOD reference book I recommend Object Oriented Analysis and Design by Grady Booch et al.

Answer 2

It's not contradictory at all.

Cohesion is about how focused the responsibilities of a given module (or class) are. The more focused, the more cohesive. A class that does only one thing is the most cohesive of all. And it's likely to be coupled to (dependent on) very few other classes, if any.

A class that is less cohesive (in other words, it has more and varied responsibilities) is likely to be coupled to many other classes. Less cohesion, more coupling.

The gist of the 'cohesive classes reduce coupling' phrase is to say that if you build smaller, focused modules, each of them will likely be less coupled than larger, less focused modules. More cohesion allows for more flexibility when composing your modules.

Answer 3

Increasing cohesion could theoretically reduce coupling in a system, but it won't in all cases.

These two quantities are not exact opposites as some imagine. For example, Patel et al say, "Information hiding seeks to minimize connections (coupling) between two different components while cohesion seeks to maximize connections within a component." [Sukesh Patel, William Chu, Rich Baxter, "A Measure for Composite Module Cohesion", ICSE '92: Proceedings of the 14th international conference on Software engineering, June 1992, pp 38–48, https://doi.org/10.1145/143062.143086]. This is incorrect, as it should never be a goal of software engineering to maximize coupling at any level!

Taken one step further, this leads to confused statements such as the following: "High cohesion with low coupling appear to be competing goals." [James M. Bieman, Byung-Kyoo Kang, "Measuring Design-level Cohesion", IEEE Trans. Software Engineering, 24(2):111-124, February 1998.]

If cohesion is properly understood as the singleness of purpose of a unit of software, then moving related pieces of code nearer to each other should increase cohesion, and may or may not reduce coupling. So these two quantities are not opposites, and they are not completely orthogonal either. This is what makes them confusing.

Answer 4

I think is totally the opposite, in the path of trying to achieve high cohesion (mostly splitting things), you will be increasing coupling, they are competing goals.

In my opinion, this misconception is doing a lot of harm. In patterns like Microservices, you seem to be reducing coupling by splitting things, where most of the time is totally the opposite. The same happens with layered architectures.

If you split your system in Controller, Domain and Persistence layers, and to add a simple property you have to touch all of them, did you decoupled your system? I don't think so, you coupled things that could be placed together. This not always should be bad, but you need to have a good reason to couple your system that way.

The most cohesive module is the one that doesn't exist or has just one small feature.The less coupled module is the one that only depends on itself.

As everything in life, the right balance is the key.