Understanding Coupling and Cohesion in Software Development

High cohesion and low coupling are software design goals that minimize interdependence between modules while ensuring each module performs a single, well-defined task. According to entwickler.de, these principles, which have been discussed since the 1960s, effectively create a “not my job” boundary for code that reduces systemic fragility and improves maintainability.

Why is “Not My Job” considered a design principle?

In professional environments, the phrase “not my job” typically signals a lack of cooperation. However, entwickler.de frames this mentality as a technical virtue when applied to software architecture. A component designed with a strict boundary refuses to execute logic that falls outside its specific purpose.

This approach prevents the creation of “God Objects,” which are classes or modules that take on too many responsibilities. When a module handles multiple unrelated tasks, it becomes a single point of failure. A change to one feature in a God Object can inadvertently break an unrelated feature within the same block of code.

By adhering to a “not my job” philosophy, developers ensure that a module only changes for one reason. This aligns with the Single Responsibility Principle, a cornerstone of modern object-oriented design that mandates a class should have only one cause for modification.

What is the difference between coupling and cohesion?

While often discussed together, coupling and cohesion describe different aspects of software structure. Cohesion refers to the internal strength of a module, while coupling refers to the external dependencies between different modules.

High cohesion occurs when all elements within a module are closely related and focused on a single task. According to software engineering standards, functional cohesion is the strongest form, where every part of the module contributes to a single, well-defined function. Low cohesion, conversely, happens when a module contains a collection of unrelated helper functions, making the code harder to understand and test.

Coupling measures how much one module relies on the internal workings of another. Low coupling is the goal, as it allows developers to replace or update one module without requiring changes to others. High coupling creates a ripple effect: a minor update to a database schema might force changes in the user interface, the business logic layer, and the reporting module simultaneously.

How do these 1960s principles apply to modern software?

The discussion of coupling and cohesion dates back to the 1960s, yet these concepts underpin current trends in cloud computing and distributed systems. The shift toward microservices is essentially an application of low coupling on a network scale.

In a monolithic architecture, coupling is often high because components share the same memory space and database tables. Microservices attempt to solve this by isolating services into separate processes that communicate via APIs. This physical separation enforces the “not my job” boundary, as one service cannot directly access the internal state of another.

However, this transition introduces new challenges. While microservices reduce code-level coupling, they can introduce operational coupling. If Service A cannot function without a synchronous response from Service B, the system remains fragile despite the architectural separation.

What are the risks of over-engineering boundaries?

Strict adherence to low coupling and high cohesion can lead to “fragmentation,” where a system is split into too many tiny, specialized modules. This can increase the cognitive load on developers who must track dozens of small files to understand a single business process.

The trade-off involves balancing the ease of maintenance against the complexity of the system’s map. Over-partitioning code can lead to “shotgun surgery,” a smell where a single logical change requires small edits across a vast number of different modules.

Effective design requires identifying the natural boundaries of a problem. When boundaries are drawn correctly, the “not my job” principle ensures that the system remains flexible. When drawn poorly, it creates unnecessary abstraction layers that slow down development without providing actual stability.