The question is – how to create components ? There are 3 basic principles.
Summary Table
Principle | Focus | Key Question Addressed |
---|---|---|
REP | Reusability & Release | Can this component be reused and released independently? |
CCP | Cohesion | Do classes that change together belong to the same component? |
CRP | Dependency Management | Is generic for interface segregation principle(ISP, not to depend on classes that have methods we don’t use) Are users of this component forced to depend on unnecessary functionality? |
These principles complement each other to ensure components are reusable, cohesive, and decoupled, which leads to cleaner and more maintainable architecture.
1. REP: Reuse/Release Equivalence Principle
- Definition: The granule of reuse is the granule of release. Only components that can be released and versioned independently should be reused.
- Meaning:
- A component should be designed so that it can be reused and released as a standalone unit.
- To facilitate reuse, the component must have a clear and well-defined API or interface.
- Components that are reused together should be versioned and released together.
- Why it’s important:
- It ensures that reusing a component doesn’t introduce unexpected dependencies or bugs.
- It makes it easier to manage and maintain components.
Example: Imagine a library that contains utilities for file handling. If developers reuse this library, it should be versioned and documented separately. Any updates to the library should not break dependent systems.
2. CCP: Common Closure Principle
- Definition: Gather into components those classes that change for the same reasons and at the same time. Separate into different components those classes that change for different reasons.
- Meaning:
- Classes that are likely to change together should belong to the same component.
- This reduces the ripple effect of changes and ensures that a change in one component doesn’t affect unrelated parts of the system.
- Why it’s important:
- It minimizes the scope of change and reduces the risk of introducing bugs.
- It aligns with the Single Responsibility Principle by grouping related responsibilities.
Example: In a payroll system:
- Classes related to calculating employee salaries (e.g.,
TaxCalculator
,BonusCalculator
) should belong to the same component. - Classes related to generating reports (e.g.,
SalaryReportGenerator
) should belong to a different component.
If tax regulations change, only the salary-related component needs to be updated.
3. CRP: Common Reuse Principle
- Definition: Don’t force users of a component to depend on things they don’t need.
- Meaning:
- Classes that are used together should be grouped in the same component.
- Avoid creating large components that bundle unrelated functionalities, forcing users to include unnecessary dependencies.
- Why it’s important:
- It ensures components remain lightweight and focused on specific functionalities.
- It prevents unnecessary coupling, improving maintainability.
Example: Consider a utility library that provides:
- File operations (
FileReader
,FileWriter
). - String utilities (
StringFormatter
,StringParser
).
If these functionalities are bundled into one library, users who need only file operations will still have to depend on string utilities. Instead, separate these into two libraries.
How These Principles Work Together
These principles help organize components effectively:
- REP ensures that components are designed for reuse and released independently.
- CCP ensures that components have high cohesion by grouping related classes together.
- CRP prevents unnecessary coupling by ensuring users only depend on what they need.