OOP Design Principles: Dependency Inversion Principle

[jimmyryan]

Ok now I know how to run a company but no clearer on the principle

[zeejenkins]

I feel like the ceo example is the exact opposite of what DI is supposed to be. In your analogy the CEO (parent class) has to tell all of its managers (children) what to do... This is the exact situation we are trying to avoid. Imagine a new type of manager is added to the company, not only do i have now write how this new child class functions but you also have to edit the parent class to now incorporate the new child class and give it instructions on what to do. The point of DI is that the child object recives everything it needs to do its job without relying on anyone else to tell it what to do.

DI inverts the dependency graph, so instead of the parent class taking in children objects and delegating tasks. The children objects take in the parent to use the information the parent contains to accomplish their specific tasks. This leaves the parent completely oblivious of what the children classes are doing.

[compscilaw]

I feel like my understanding is a bit different.

I thought that Dependency Inversion meant that you should have the base and child classes depend on an abstraction, usually an interface.

For instance

IAuth {
isUserLoggedIn():bool;
getUser(): User;
login();
}

So that when you're using something that implements IAuth, you instead reference the IAuth interface. This way your concrete implementations can be swapped as long as they implement IAuth. Say, your boss comes to you and says, "Well the username and password logins were great, but we just bought all these finger print scanners ..." If you satisfy the interface for the new print scanners, the code that uses the IAuth doesn't have to change. Also, dependency INJECTION helps such as a factory and Service Locator. Now your code knows nothing about the concrete implementations and it doesn't know what concrete object it will receive.

[darianamsanchez]

good analogy and examples to explain the principle
well done

[ifstatementifstatement]

Another guide I read explained that dependency inversion was about using setters and getters to take control over how variables are assigned and read.

[zhoushujian]

An good analogy and clear explanations👍

[allentom]

Fantastic explanation, very good use of different stages of a company to explain. My lecturer made no sense as he was saying this depends on this which doesnt depend on that, but that depends on this and was very confusing!

[tmnvanderberg]

I love the composition (table, window, board)

[-.._.-_...-_.._-..__..._.-.-.-]

So, it's like a chain of command.

[Name-lttz]

code sample would be good also. I will search for another video which shows code samples.

[rodrigomaldonado]

I'd prefer more examples and cases where we make mistakes so we use this principle. Thanks anyway :)

[xsctzkr]

it was well explained until u mentioned rupy lan bec its a complicated part

[excellins]

Good luck with the coding? wish i saw one here. Nice video by the way

[mikeimin]

Nice comparison code deps with company employees hierarchy!

[JR-mkow]

That was not a great first example.
I'll give it a try. Imagine that a machine makes Coca Cola. The receipt is our code.
It follow a receipt and it has to use 10 kgs of SugarO. It's a brand of sugar.
If SugarO had a problem the machine that makes Coca Cola can't follow the receipt anymore.
A solution would be to make the receipt depends on an Abstraction / Interface called SugarInterface and having the machine using 10 kgs of SugarInterface
So you would "connect" SugaRO to the Coca Cola between the interface.
What's the advantage?
You can change the supplier (SugarO) and the machine that makes Coca Cola would continue to work without any change. You would only had to change how the interface "asks" sugar to the supplier.
This prevents code spaghetti in the long run (or even during development processes).

[kirill]

I would like to see an example of a class with and without following DIP

[ignazioc]

the explanation is confusing and leads to the wrong understanding of this principle. The part of this principle that says "both should depend on abstractions" gives a clear hint that this principle applies to two different classes at a different level of abstraction. A more fitting example would be a logging framework and a specific IO function. The logging framework should never depend on the concrete IO function but should depend on abstraction (aka interface). As well the abstraction (aka interface) should not depend on details (the IO Function). In other words, would be very stupid to create an interface on top of a very specific IO function BUT "Details should depend on abstractions" in other words is the "IO function" that needs to be adapted to work with the abstraction required by the layer above.

[gwho]

i find your explanations accurate and simple, but leaving me with not a real full understanding - too simple.