Cohesion and coupling are two crucial concepts in software design that determine how well modules or classes in a system work together. They are not a combined concept; rather, they are two separate yet related measurements.
Understanding Cohesion
Cohesion refers to how closely related the responsibilities within a module or class are. A module or class with high cohesion performs a single, well-defined task. Conversely, low cohesion means the module or class is responsible for multiple unrelated tasks. According to the provided reference:
Cohesion refers to how closely the responsibilities of a module or class are related to each other. It measures how focused and unified a module or class is in terms of its functionality.
Types of Cohesion
- Functional Cohesion: The strongest form of cohesion, where all parts of a module contribute to a single, well-defined task.
- Sequential Cohesion: Module parts are related because they are executed in a sequence. The output of one part becomes the input of another.
- Communicational Cohesion: Module parts operate on the same data.
- Procedural Cohesion: Module parts are grouped because they follow a certain control flow.
- Temporal Cohesion: Module parts are related by being executed at the same time.
- Logical Cohesion: Module parts perform similar but different tasks.
- Coincidental Cohesion: The weakest form where module parts are completely unrelated.
Understanding Coupling
Coupling measures the degree of dependency between modules or classes. A system with high coupling means modules rely heavily on each other, and changes in one module can cascade to others. Low coupling is desirable, making modules independent and reusable. The provided reference explains:
Coupling refers to how dependent one module or class is on another module or class.
Types of Coupling
- Content Coupling: One module directly modifies the internal data of another module (very high coupling and not recommended).
- Common Coupling: Modules share common (global) data, making it difficult to trace the impact of changes.
- Control Coupling: One module controls the flow of another module by passing flags or control codes.
- Stamp Coupling: Modules share a data structure. Changes to the data structure affect both modules.
- Data Coupling: Modules communicate through parameters that are data (ideally, this is the lowest coupling).
- No Coupling: Modules are independent.
Cohesion vs. Coupling: Key Differences
| Feature | Cohesion | Coupling |
|---|---|---|
| Definition | Measures the relatedness of responsibilities within a module. | Measures the dependence between modules. |
| Goal | Aim for high cohesion; a focused, well-defined module. | Aim for low coupling; independent, reusable modules. |
| Impact | High cohesion makes a module understandable and maintainable. | Low coupling makes a system flexible, robust and easier to modify. |
| Ideal State | Ideally, modules should perform a single, well-defined task. | Modules should not overly rely on each other and be self-contained. |
Practical Insights
- High Cohesion + Low Coupling = Good Design: This combination leads to modular, maintainable, and robust software.
- Low Cohesion + High Coupling = Bad Design: This results in brittle, complex systems difficult to change and reuse.
- Refactoring: Regularly analyze modules for cohesion and coupling, refactoring as needed to improve the design.
- Code Reviews: Code reviews help identify and address cohesion and coupling issues early in the development process.
Conclusion
Cohesion and coupling are vital for good software design. High cohesion and low coupling contribute to maintainability and robustness in software systems, whereas the opposite leads to brittle and less efficient designs.
