A Guide to Loose Coupling and Writing Better Python Code With Dependency Inversion | by Haseeb Kamal | Apr, 2022

Photograph by Rachel Nickerson / Unsplash

This put up is an element 5 of a sequence on the SOLID ideas.
Yow will discover put up 4 here, put up 3 here, put up 2 here and put up 1 here.

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.

Supply: Dependency inversion principle — Wikipedia

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:

The Robotic class has just one operate get_energy.
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:

Robotic with dependencies on Apple and Chocolate

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 Apple and Chocolate.
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 Chocolate or Apple.

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.

The precept:

  • 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.

More Posts