Developer Stories

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.


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.

    Hello!👋🏽 My name is Mustafa Hussain.
    I am a software engineer who spends the majority of his time seeking out new, innovative solutions related to the software engineering. That being said, I always do my best to develop high-quality backend solutions for my clients.
    In the 7+ years that I have spent as part of the software engineering industry, I have managed to build a lot of stuff that helped me to improve both my collaboration skills and my analytical skills. Building highly scalable backend services is something that I am always interested in.
    Apart from being a software engineer, I also like to spend some of my time reading📚, brewing coffee☕️ and doing a long distance running 🏃🏾.