Developer Notes

Software Components

April 06, 2019 , ☕️ 4 min read

Photo by Fancycrave on Unsplash

Components are the units of deployment, they are the smallest entity that can be deployed as part of the system, In Java, they are Jar files, In Ruby, they are gems files.

Components can be linked together into a single executable or they can be independently deployed as separate plugins, regardless of how they have eventually deployed well-designed components always retain the ability to be independently deployed and developed.


We will discuss a little how we can design a cohesive software component, we will discuss principles of components cohesion which uncle bob defined them in details in his book clean architecture.

  • REP: Reuse-Release Equivalence principle.
  • CCP: Common Closure Principle.
  • CRP: Common Reuse Principle.

REP: Reuse-Release Equivalence Principle

the granule of reuse is the granule of release.

To reuse a software component you can’t do so unless that component tracked through a release process and is given a release number because without a release number there would be no way to ensure that all the reused components that you’re using are compatible with each other.

This principle means that the classes and modules that are formed into a component must belong t a cohesive group. a software component can not consist of random classes and modules there’s must be some overarching theme of purpose.

CCP: Common Closure Principle

gather into component those classes that change for the same reason and at the same time separate into different components those classes that change at a different time and for different reasons.

The CCP is the component form for the SRP, while the SRP tells us to separate methods into different classes if they change for different reasons, the CCP tells us to separate classes into different components if they change for different reasons.

CRP: Common Reuse Principle

Don’t force users of a component to depend on things they don’t need.

The CRP is a generic version of the ISP, while the ISP advised us not to depend on classes that have methods we don’t need the CRP advice us not to use components that have classes we don’t need.

CONCLUSION

Finally, that was a very simple introduction to how to develop a cohesive component, helping you to take the decision of which classes belong in which components.

Edit on GitHub

Subscribe to the Newsletter

Subscribe to get my latest content by email.

    I won’t send you spam.

    Unsubscribe at any time.

    Written by Mustafa Hussain cloud Application Developer @IBM. You can follow me on Twitter or check my github