People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and given release numbers
Reflects the fact software developers need to know when new releases are coming and which changes they will bring
Developers rely on alerts for new releases and decide changes from there, therefore, appropriate notifications and documentation must be produced
From a software design and architecture POV, it means classes and modules formed into a component must belong in a cohesive group
Classes and modules grouped together should be releasable together
It should make sense for them to have the same version number, release tracking and be included under the same release documentation
CCP
Components should not have multiple reasons to change
Most of the time, maintainability is more important than reusability
If some code were to change, you'd rather it all occur in one component than many components
Changes confined to a single component are easier to redeploy
Complete closure is not attainable but we can design classes in a way that they are resistant to the most common kinds of changes
It shares similarity with SRP, where methods are separated into different classes
In CCP, classes are separated into different components
Both principles can be summarised by the sound bite:
" Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons."
CRP
A principle that helps us deide which classes and modules should be placed into a component
It states classes and modules tend to be reused together belong in the same component
We want to ensure all classes we put into a component are inseparable
Should be impossible to depend on some classes and not on others, otherwise it will cause more redeployments
CRP tells us which classes shouldn't be together and should be together, if they aren't tightly bound then they should not be in the same component
This principle is the generic version of ISP, advising us not to depend on components that have classes we don't use
Hence, "Don't depend on things you don't need"
Tension Diagram for Component Cohesion
REP and CPP are inclusive principles, trying to make components larger
CRP is an exclusive principle, driving components to be smaller
Focusing on REP and CRP will result in components that are greatly impacted from only simple changes
Focusing on CCP and REP will cause too many unneeded releases to be generated
A good architecture finds a balance that meets the current concerns of the development team, but is aware these concerns will change over time
Ex. CCP is more important than REP early on
Conclusion
In the past, our view of cohesion at the modular level was simpler than what these principles implied
These three principles describe a complex variety of cohesion at the component level and finding the balance with the needs of the application
Consequently, the composition of components will evolve as the focus of the project shifts from the ability to develop to reusability