How to effectively structure your software components?
One of the most important challenges when designing a software architecture is to effectively define your software components in such a way that they can be reused and deployed easily.
But before we dig into details let’s start by defining a software component.
A software component can be defined as the smallest entity that can be independently deployed. It can be a software package or web service, a module supplied as Software development Kit (SDK) or simply a DLL. So a component is a grouping of functions, data that are semantically related. Each component much provide interfaces to interact with it without worrying much about the encapsulated logic.
In his book Clean Architecture, A Craftsman’s Guide to Software Structure and Design, Robert C.Martin the famous programmer known as “Uncle Bob”, exposed multiple aspects of his knowledge built along years starting from SOLID principles to Architecture principles and Testing. But in this article we will zoom on 3 principles that addresses our subject which are:
- REP: The Reuse/Release Equivalence principle.
- CCP: The Common Closure Principle.
- CRP: The Common Reuse Principle.
The Reuse/Release Equivalence Principle (REP):
In simple words Robert C.Martin define this principle as:
“ The granule of reuse is the granule of release”
So classes that tend to be delivered together should be grouped inside the same component and they should also be tracked with a release number and have proper documentation that describes in a clear way the change log. Otherwise their usability is impossible for others that depends on this component.
The Common Closure Principle (CCP)
This principle consists in grouping the classes that change together inside the same component. So a change of some classes inside a given component should not force other components to change.
This principle has a similarity with the Single Responsibility Principle in the way that a component should have only one reason to change. So if two classes have different reason to change then they should be dispatched in two separate components.
This principle will increase the code maintainability as a change will take place inside one component.
The Common Reuse Principle (CRP)
In simple words this principle states that classes that tends to be used together should be placed inside the same component. Which means that the classes residing in a given component should be inseparable. So if you depend on a given component then you should depend on all of its classes not only few methods.
CRP aims to reduce unnecessary strong links between components. If a component depends on a single method within another component. Then any change or new release within the later implies a compatibility check and a new delivery of the dependent component.
So which principles to apply?
The above principles seems to have some clashes between them as REP and CRP pushes to have bigger component with multiple classes that are semantically and logically linked and these classes should be released and used together. While CCP is trying to make components smaller so that a component contains only few classes that necessarily changes together. So you can not apply them all together.
If an architect is focused on CCP and REP only then the team will be burdened by too many unnecessary releases and if he shifts his focus only to REP and CRP then too many components can be impacted by a simple change.
As the choice seems to be impossible between all these principle then we should add the team current situation and project maturity into consideration. As projects in early stage tends to push releasability to a more advanced stages as the main focus is shifted to easy changes to make the project advances faster. and with a more mature project then the focus can be shifted to REP.
Source : Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C Martin)
Thanks for reading :)
