Cohesion and coupling are two ideas used to judge how well a software system is divided into modules. They were developed by Larry Constantine and popularized in the book “Structured Design” by Edward Yourdon and Larry Constantine, which expanded on the concepts first set out in their 1974 IBM Systems Journal paper of the same name.
Cohesion measures how closely the parts of a single module belong together. A highly cohesive module does one well-defined job, so all of its code is focused on a single purpose. A module with low cohesion bundles unrelated responsibilities together, which makes it harder to understand and to reuse. The design goal is high cohesion.
Coupling measures how much one module depends on the internals of another. Tightly coupled modules must change together, because each one relies on details of the other; loosely coupled modules communicate through narrow, stable interfaces and can be changed independently. The design goal is low coupling.
Taken together, the rule of thumb “high cohesion, low coupling” became one of the most durable guidelines in software design. It is closely related to David Parnas’s principle of information hiding, which gives a criterion for where module boundaries should fall, and both ideas underpin encapsulation in object-oriented programming.