Mastering Software Design: Why High Cohesion and Low Coupling Matter

1. Significance of Design Principles

To design a good software system we must follow certain rules. The primary metric for software design quality is whether the design satisfies functional requirements. Additional quality attributes include readability, reusability, extensibility, and maintainability.

1.1 Characteristics of Good Software

Readability : Documentation should be easily understood by other developers; poor readability harms large‑scale development and maintenance.

Reusability : Architecture, classes, components, etc., should be easily reused within the same project or other projects.

Extensibility : The difficulty of adding new functionality or improving performance when requirements change.

Maintainability : The ease of fixing bugs or adding missing features.

2. Cohesion and Coupling

2.1 Cohesion

Cohesion measures how many related responsibilities a single unit (class or method) handles. High cohesion means a unit performs a single, well‑defined task, making it easier to understand, reuse, extend, and maintain. Naming conventions like loadFile() or class names such as Employee indicate high cohesion.

2.2 Coupling

Coupling describes how tightly classes are linked. Low coupling allows a class to change without forcing changes in other classes, whereas high coupling makes modifications ripple throughout the system. The ideal is “high cohesion, low coupling,” which yields better reusability, extensibility, and maintainability.

3. The Seven Design Principles (SOLID)

3.1 Single Responsibility Principle (SRP)

Each class should have only one reason to change, meaning it should have a single responsibility.

3.2 Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification. Abstract classes or interfaces enable this in languages like Java.

3.3 Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without altering the correctness of the program. Violating LSP breaks OCP.

3.4 Dependency Inversion Principle (DIP)

High‑level modules should depend on abstractions, not concrete implementations; abstractions should not depend on details. This inverts dependencies toward interfaces or abstract classes.

3.5 Composite/Aggregation Reuse Principle (CARP)

Prefer composition or aggregation over inheritance to achieve reuse, treating objects as “has‑a” relationships.

3.6 Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they do not use; split large interfaces into smaller, role‑specific ones.

3.7 Law of Demeter (LOD)

Also known as the “least knowledge” principle, a module should communicate only with its immediate friends, reducing ripple effects of changes.

4. Illustrative Example

The diagram below shows how different requirements (flying vs. feather characteristics) affect whether an ostrich can be considered a bird in a given context.