You could follow the previous posts here:
If the SOLID principles tell us how to arrange the bricks into walls and rooms, then the component principles tell us how to arrange the rooms into buildings.
III. Component Principles
Components are the units of deployment. They are the smallest entities that can be deployed as part of a system. In Java, they are jar files. In Ruby, they are gem files. In .Net, they are DLLs.
1. Component Cohesion
Focus on the granularity of components and help the developer partition classes into components.
Uncle Bob gave us three principles of component cohesion:
REP: The Reuse/Release Equivalence Principle
- Classes and modules that are grouped together into a component should be releasable together, share the same version number, are included under the same release documentation
- Classes and modules that are formed into a component must belong to a cohesive group
- If a component should be considered reusable it must be a releasable unit
CCP: The Common Closure Principle
- Gather into components those classes that change for the same reasons and at the same times.
- Separate into different components those classes that change at different times and for different reasons.
- this is Single Responsibility Principle for components
- A class should not contain multiple reasons to change
- Drive components to be larger
CRP: The Common Reuse Principle
- Don't force users of a component to depend on things they don’t need
- Drive components to be smaller
2. Component Coupling
Focus on the stability and relationship between the components
Acyclic Dependencies Principle
- Allow no cycles in the component dependency graph
Stable Dependencies Principle - SDP
- Depend in the direction of stability
- I : Instability : I = Fan-out / (Fan-in + Fan-out)
with Fan-in : Incoming dependencies, Fan-out : Outgoing depenencies
- I metric (Instability) of a component should be larger than the I metrics of the components that is depends on => I metrics should decrease in the direction of dependency
- Not all components should be stable
Stable Abstraction Principle - SAP
- A component should be as abstract as it is stable
- The software that encapsulates the high-level policies of the system should be placed into stable components (I = 0), Unstable components (I = 1) should contain only the software that is volatile (quickly and easily change)
- A stable component should also be abstract so that its stability does not prevent it from being extended (Ex: interface, abstract class)
- Unstable component should be concrete since its instability allows the concrete code within it to be easily changed
with Abstractness A = Number of abstract classes and interfaces / number of classes
Dependencies run in the direction of abstraction
Uncle Bob also give us the concept Zones of Exclusion
with:
- Zone of Pain : highly stable and concrete component
=> cannot be extended because it is not abstract, very difficult to change because of its stability.
- Zone of Useless : maximally abstract, yet has no dependents
=> such components are useless :)))
Good architects strive to position the majority of their components at endpoints on the Main Sequence.
=> But in reality, those components have the best characteristics if they are on, or close, to the Main Sequence.
(to be continued