'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.

  • @gnat Actually I believe the purpose of the question is to answer how cohesion reduces coupling rather than asking for OOD resources.
    – Random42
    Aug 6, 2013 at 6:53
  • @m3th0dman my note relates to 1st revision question, prior to your edits: "could you tell in a correct order which books people need to follow blah blah"
    – gnat
    Aug 6, 2013 at 7:00
  • @gnat Before I edited, the question I believe it was something like this: "does this statement hold true?" Anyway, it still asks two distinct questions in one message.
    – Random42
    Aug 6, 2013 at 8:11
  • My apologizes, I made two different questions to show how much perception I (don't) have about OOD. Aug 6, 2013 at 16:19

4 Answers 4


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.


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.


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.


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.

  • I think you are missing the point, regarding dependency and usage as coupling. They are not the same thing. Splitting up a system in building blocks is beneficial as long as you separate sensibly. That is where coupling comes in. If you split up poorly, making the wrong decisions about what goes where, you will end up with not very cohesive modules and tight coupling between them. So there is a relation and improving one will benefit the other. Aug 11, 2021 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.