Dive into the favored design sample
Now we have lastly reached the final of the SOLID ideas. As normal, we begin with a definition:
Precept 5 is called the dependency inversion precept. The definition has two elements:
A. Excessive-level modules mustn’t import something from low-level modules. Each ought to rely on abstractions (e.g., interfaces).
B. Abstractions mustn’t rely on particulars. Particulars (concrete implementations) ought to rely on abstractions.
In conventional software program structure we design decrease degree parts for use/consumed by increased degree parts. In different phrases, increased degree parts rely on decrease degree parts. This dependency causes tight coupling within the software program. As defined in precept one, we attempt to attain free coupling to make it simpler to develop, preserve and alter code sooner or later.
The dependency inversion precept inverts this dependency within the sense that as a substitute of upper degree parts relying on decrease degree ones, each ought to rely on abstractions. This abstraction layer could be an intermediate element that sits between the upper and decrease degree parts. The 2 will then use this element to speak and work together amongst one another. The abstraction element would normally be carried out as an interface.
Time for some code and a concrete instance!
Take into account the next instance the place we mannequin a robotic:
Robotic class has just one operate
We mannequin an
Apple that the robotic can get power from.
Now, sooner or later the robotic will get bored with consuming apples.
So we add a
Chocolate class to supply extra consuming choices to the robotic.
Discover nevertheless, what occurs to the
get_energy technique. We should go a string as a parameter indicating what eatable the robotic ought to eat. Additionally, we should use if-else branching on the 2 completely different eatables. Now you possibly can think about if extra eatables are added we would want extra else branches. This isn’t good design.
Moreover, as a result of
Robotic has a dependency on every of the person eatables we are going to run into points if the implementation of one of many eatables modifications. For instance, if we introduce an extra parameter to the
eat technique in
Chocolate the code in
get_energy would break and we must refactor it to mirror the modifications in
Chocolate. These points happen as a consequence of tight coupling and sturdy dependencies and are a violation of the dependency inversion precept.
Presently our structure seems as follows:
To resolve this, we have to introduce an abstraction layer.
We modify the structure as follows:
The code seems like so:
We create an
Eatable interface that’s carried out by each
We alter the strategy signature of
get_energy in order that it expects an argument of kind
Eatable as a substitute of
str. This implies we are able to eliminate the if-else branching. Moreover, since all eatables implement the
Eatable interface we’re positive that there can be no code breakage if there modifications to
On this put up, we appeared on the dependency inversion precept. The precept basically states that increased degree modules mustn’t rely on decrease degree modules. As an alternative each ought to rely on abstractions. We make increased degree modules unbiased of implementation specifics in decrease degree modules.
- Implement free coupling and thereby helps make code extra sturdy in face of modifications.
- Permits re-use of higher-level parts for the reason that abstraction layer prevents code breakage in case the lower-level parts must be modified.
Now we have lastly reached the top!
I hope you loved this put up and all of the earlier posts on the SOLID ideas.