Why High Cohesion and Low Coupling Matter: Design Principles and Patterns Explained

Module

A module logically decomposes a system into finer parts, applying divide‑and‑conquer to break complex problems into simpler ones that can be solved individually.

Coupling mainly describes the relationships between modules, while cohesion describes the internal relationships within a module. Module granularity can vary—it may be a function, class, feature block, etc.

Coupling

Modules may depend on each other, causing changes in one to affect the other; the tighter the relationship, the stronger the coupling and the poorer the module independence.

For example, if module A directly manipulates data inside module B, this is strong coupling; if A only interacts with B through data exchange, it is weak coupling.

Independent modules are easier to extend, maintain, and unit‑test. Heavy inter‑module dependencies dramatically reduce development efficiency.

Cohesion

When the elements inside a module are highly related, cohesion is high and the module’s single responsibility is stronger. A module should aim to accomplish a single function independently.

If many different scenarios need to be introduced into the same module, the code becomes fragile; in such cases, splitting into multiple modules is recommended.

Low‑cohesion modules are difficult to maintain, extend, or refactor.

Interface Design Principles

A good interface should satisfy the six principles of design patterns; many frameworks are built on the premise of high cohesion and low coupling.

Single Responsibility Principle: a class should have only one reason to change.

Open/Closed Principle: software entities should be open for extension but closed for modification.

Liskov Substitution Principle: objects of a superclass must be replaceable with objects of a subclass without affecting correctness.

Dependency Inversion Principle: abstractions should not depend on details; details should depend on abstractions. Program to interfaces, not implementations.

Interface Segregation Principle: use many specific interfaces rather than a single general one; clients should not be forced to depend on interfaces they do not use.

Law of Demeter: a software entity should have minimal knowledge of other entities, e.g., the Facade pattern provides a unified external interface.

Examples

Facade Pattern

Provides a unified external call for multiple subsystems, hides subsystem details from the client, and reduces coupling.

Bridge Pattern

In JDBC, the vendor‑specific interface (Driver) is separated from the user‑facing API (DriverManager).

// Developers only need to focus on the JDBC API, without worrying about different driver implementations
Class.forName("com.mysql.jdbc.Driver");
Connection conn = DriverManager.getConnection(url, username, password);

Adapter Pattern

When introducing third‑party libraries (e.g., Hibernate, Log4j), you should not directly inherit or use their entity classes. Instead, extract a higher‑level interface, add implementation classes, and expose the interface.

// Code tightly coupled with log4j – not recommended
org.apache.log4j.Logger.getRootLogger().info("info");
// Underlying logging framework can be swapped freely
FRLoggerFactory.getLogger().info("info");