Cohesion measures how closely related and focused the responsibilities of a single module, class, or component are. High cohesion means that a module's elements all contribute to a single well-defined task. Low cohesion means a module handles many unrelated responsibilities, making it harder to understand, maintain, and reuse.
## Levels of Cohesion (Worst to Best)
Larry Constantine and Edward Yourdon identified seven levels, from weakest to strongest:
### 1. Coincidental cohesion (worst)
Elements are grouped arbitrarily with no meaningful relationship. Example: a `Utilities` class containing unrelated helper methods.
### 2. Logical cohesion
Elements perform similar operations but are otherwise unrelated. Example: a class that handles all types of input (keyboard, file, network) just because they're all 'input.'
### 3. Temporal cohesion
Elements are grouped because they execute at the same time. Example: an `init()` function that sets up unrelated subsystems because they all happen at startup.
### 4. Procedural cohesion
Elements are grouped because they follow a specific sequence. Example: a function that validates input, opens a file, reads data, and writes a report.
### 5. Communicational cohesion
Elements operate on the same data. Example: a module that reads, transforms, and validates a customer record.
### 6. Sequential cohesion
Output from one element serves as input to the next. Example: a pipeline where each step transforms data for the next.
### 7. Functional cohesion (best)
Every element contributes to a single, well-defined task. Example: a `PasswordHasher` class that only deals with hashing passwords.
## Why High Cohesion Matters
- **Understandability**: A cohesive module can be described in one sentence
- **Reusability**: Focused modules are useful in more contexts
- **Maintainability**: Changes are localized to one module
- **Testability**: Clear purpose means clear test cases
- **Naming**: If you can't find a good name for a class, it probably lacks cohesion
## Cohesion and Coupling
Cohesion and coupling are two sides of the same coin:
- **High cohesion**: Things that belong together are together
- **Low coupling**: Things that don't belong together are separated
Good design maximizes cohesion within modules and minimizes coupling between them. These goals reinforce each other — highly cohesive modules naturally have fewer reasons to depend on each other.
## The Naming Test
A practical test for cohesion: can you describe what a module does without using the words 'and,' 'or,' or 'also'? If not, it probably has multiple responsibilities and low cohesion.
## Beyond Software
Cohesion applies to any organized system:
- **Teams**: A team focused on one product area is more cohesive than one handling unrelated projects
- **Documents**: A chapter about one topic is more cohesive than one covering many
- **Meetings**: A meeting with one clear objective is more cohesive than one with a grab-bag agenda
- **PKM notes**: Atomic notes (one idea per note) are the ultimate expression of cohesion in knowledge management