CODEWITHSUNDEEP
solid-principlesdependency-inversion
Ron8320
Ron8320

Reputation: 11

Dependency Inversion Principle

I'm trying to learn SOLID Principles and I am very confuse with this dependency Inversion principle.

Can someone explain and see if my code below violates the mentioned principle?

Sorry for the messy code. asking this through my phone.

interface IFact{

Public int FindFact();

}

Class Factorial1:IFact{

//Itretive implementation for finding factorial

}

Class Factorial2:IFact{

//Recursive implementation for finding factorial

}

Class Factuser{

IFact fact;

Public FactUser(IFact f){

fact=f;

}
Public Calculate (int num){

Fact.findfact(num);

}




//Main method implementation
Main(){

Factuser obj=new Factuser(new Factorial2 ());
Int ans=obj.Calculate(5);

}

Upvotes: 0

Views: 217

Answers (1)

geoffrey
geoffrey

Reputation: 2454

This answer is going to be unconventional but that's probably what you are looking for since plenty of more academic answers exist.

At the end of the day, Factuser is dispatching Factorial2 methods. It literally needs to access that part in memory where they are stored. We can say Factuser depends on Factorial2 at runtime.

Had you implemented Factuser with no injection via the constructor, it would have had to mention the name of Factorial2 in order to instantiate it and use it (and the other variant as well). In other words, Factuser would have depended on Factorial2 in the source code as well. In such case we say the source code dependencies flow in the same direction as the runtime dependencies.

Instead, you made both Factuser and Factorial2 mention the name of a common interface, IFact, which they both have to look up in their source code. What this achieves is decoupling Factuser from a specific implementation of IFact, and that's good. However, it doesn't mean Factorial2 is now magically depending on Factuser. Indeed, programming to an interface on itself is not inverting anything, it's just adding an indirection.

The inversion happens if you split the code in different modules and you decide that the IFact interface is owned by the user module. This module doesn't need to mention any name from the outside world, so it doesn't depend on anything. On the other hand, the module containing Factorial2 needs to import IFact from the user module and now depends on it. To sum it up: the implementations module depends on the user module, which is the opposite of the runtime dependency, we have our inversion.

Upvotes: 3

Related Questions