Notes on Component Cohesion

In this post, I summarize the three component principles regarding component cohesion which I learned from reading the book “Clean Architecture : A Craftsman’s Guide to Software Structure and Design” by Robert Martin. The three principles are: The Reuse/Release Equivalence Principle, The Common Closure Principle, and The Common Reuse Principle.

The Reuse/Release Equivalence Principle (REP)

To reuse a component, developers need to know when a new release of the version comes out, be able to compare the changes in the new release and an older release to make a decision whether to upgrade or continue to use the old one.

REP’s guideline is that classes and modules under a same component should be releasable together. For example, they should be given the same version number, referred by the same documentation, and tracked under the same release tracking.

The Common Closure Principle (CCP)

This principle is a version of the Single Responsibility Principle, but for components. CCP advises that classes in a component should have same reasons to change, whereas classes outside the component should have different reasons to change.

This principle has helped me to decide whether to group classes together under a namespace or folder. Following the principle, if two classes relate to each other such that if I need to make changes to both classes for a same reasons, then I consider putting both classes under a same namespace. On the contrary, if I have to make changes to one class without having to change the other class, then I consider placing the classes under different namespaces.

By putting classes that can change for same reasons into a same component, we can reduce the effort of deploying and releasing components. This is because we don’t have to rebuild or redeploy other components if they don’t depend on the changed component.

The Common Reuse Principle

This principle states that classes that do not depend on each other should not be in a same component. This is because whenever a class in one component depends on a class in another component, you have established the dependency between the two components. It does not matter if the using component only depends on one class out of the many classes in the used component, the dependency is still there. Because of the dependency, whenever the used component changes, the using component may need to change as well, even though the changes may not have anything to do with the using component. Therefore, we should avoid coupling components. When a component depends on another component, it should be the case that the component depends on most or all the classes in the other component.

In summary,

• The Reuse/Release Equivalent principle suggests that classes in a component should be releasable together.

• The Common Closure Principle suggests that classes within a component should have same reasons to change.

• The Common Reuse Principle suggests that classes that do not depend on one another should not belong to a same component.

References

Clean Architecture: A Craftsman’s Guide to Software Structure and Design