High Cohesion
High cohesion refers to the strength of the interrelationships between elements within a module.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeDesign
- Organizational maturityAdvanced
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Misunderstandings in modularization.
- Lack of integration between highly cohesive modules.
- Insufficient documentation can lead to confusion.
- Conduct regular code reviews.
- Clearly define module boundaries.
- Keep documentation up to date.
I/O & resources
- Existing documentation for the application
- Requirement documents
- Feedback from users
- Clean, well-structured code
- Documentation for modules
- User-friendly interfaces
Description
High cohesion is a principle in software architecture aimed at ensuring that modules perform closely related functions. This results in improved maintainability, reusability, and understandability of code, as changes in a high-cohesion module have less impact on other modules.
✔Benefits
- Increased maintainability
- Better reusability
- Clearer structure
✖Limitations
- Excessive modularization can impact performance.
- High cohesion can jeopardize reliability in some situations.
- Difficulties in adapting existing modules.
Trade-offs
Metrics
- Number of Modules
Number of developed modules exhibiting high cohesion.
- Code Reusability Rate
Percentage of code that is reused.
- Maintenance Effort
Effort required for code maintenance and upkeep.
Examples & implementations
E-Commerce Platform
A modular e-commerce system that promotes high cohesion by grouping related functions into separate modules.
Content Management System
A CMS with well-structured modules to facilitate maintainability and reusability for editors and developers.
Financial Application
An application leveraging high cohesion to achieve a clear separation between various financial processes and functions.
Implementation steps
Create a comprehensive architecture plan
Develop and test modules
Gather feedback from stakeholders
⚠️ Technical debt & bottlenecks
Technical debt
- Legacy code that has not been refactored.
- Weak tests that undermine confidence.
- Lack of documentation leads to knowledge loss.
Known bottlenecks
Misuse examples
- Functions that are overloaded in a single module.
- Disregarding modular principles.
- Lack of documentation for modules.
Typical traps
- Emphasizing modularity but neglecting cohesion.
- Neglecting lack of integration.
- Being sloppy in the implementation of modules.
Required skills
Architectural drivers
Constraints
- • Collaboration between development teams is required.
- • Clear documentation must be available.
- • The software must integrate with existing systems.