Low Coupling and High Cohesion: simple with diagrams

Short description

Low coupling and high cohesion have been around for a long time as part of the GRASP patterns. However, the difference between coupling and cohesion is subtle. Many developers tend to mix them up, or understand only one (usually coupling) but not the other.
Please, keep in mind, that this article reflects my own interpretation of the concepts of cohesion and coupling as presented in Clean Code by Robert C. Martin.

This note covers following questions:

• What’s the difference between coupling and cohesion?
• When does coupling become cohesion?
• Why can’t coupling exist without cohesion?

Coupling and Cohesion

Coupling and cohesion are closely related concepts. The confusion often comes from the language itself — the words sound similar and are sometimes used interchangeably in everyday conversation.

Both measure communication or dependency between entities. The difference lies in the level at which the communication happens:

• Cohesion: interaction between elements inside the same module.
• Coupling: interaction between different modules.

When Does Coupling Become Cohesion?

Remember:

• Cohesion = communication between elements inside a module
• Coupling = communication between a module and something outside it As abstraction level raises, so does the definition of the module. So in the scope of the package, what used to be a coupling in the scope of the classes - becomes cohesion.

Low Coupling, High Cohesion

That's why the pattern is called Low Coupling, High Cohesion because the two are linked — you can’t have one without the other — but coupling introduces risk.

The goal is to keep coupling as low as possible. That means minimizing and controlling the points where modules depend on each other(coupling points), while keeping cohesion high within each module so it’s internally well-organized.

Real life Examples:

• Low coupling: Other departments communicate with IT only through the CTO. This creates a single, stable point of contact, reducing miscommunication and making the system more resilient. The main risk is if the CTO changes, but that’s a controlled and infrequent event.
• High coupling case: Other departments talk directly to individual developers. This increases risk and instability because many points of dependency can change frequently. It’s far harder to guarantee stability here.

Why Not Reduce Both?

You might think: If coupling (the bad guy) and cohesion are tied together, why not lower cohesion to reduce coupling?

Because low cohesion breaks the Single Responsibility Principle (SRP). Cohesion between internal elements ensures each part has a clear, minimal responsibility.

Imagine merging the Sales and IT departments into one hybrid “Sales-IT” team. Technically, there’s no coupling between them anymore — they’re one module. But now the team violates SRP, and the risks of having unrelated responsibilities mixed together outweigh the benefits.

So, the better approach is:

• Keep high cohesion inside your modules
• Keep loose coupling between modules

Sum up

• Cohesion - communication inside one module
• Coupling - communication between different modules
• Coupling and Cohesion are linked, one does not exists without the other.
• Keep coupling low by reducing the number of coupling points.

Information and inspiration source

• Clean Code by Robert C. Martin