Dependency Inversion - how, what, why? (examples in C#) | Code Walks 004

CODE EXAMPLES FROM 4:00.
Dependency inversion is the D in the SOLID design principles. But what does it really mean? Let me give you a no-nonsense explanation of what it is, why it is so incredibly important and how you go about using it.
Subscribe for more programming knowledge.
Suggestions for topics are very welcome :)
Original upload date:
Apr 23, 2016

[@narayanadhurti1603]

Hi Chris your videos transform people into real programmers.

[@ChristopherOkhravi]

Wow. Thank you very much for your kind words :) I do my best, and I may often be wrong. But together I'm sure we'll be able to make software work better :)

[@protyaybanerjee5051]

This is great. I mean the way you have explained DIP. It was always about Unit Testing and Abstraction. But the design concept extends to support composition over Inheritance is where I think this video stands out. Keep walking !

[@ChristopherOkhravi]

Protyay Banerjee Thanks for the feedback! I'm glad. Haha, I will :)

[@radhikagadve]

there are no better coding videos than these code walks on the internet for me... keep doing more thanks

[@pulkitprajapat7862]

you make understanding easy of such topics, hope you will be back to youtube soon.

[@codeelsewhere1688]

first time after reading so many articles I could understand this concept. thanks mate. you have a great explaining skill. cheers.

[@tttggg63]

Great work! Your videos are the best I've found on SOLID so far. Keep up the good work.

[@bigbeneconotmyjob6474]

Probably the best explanation I have heard, I can visualize the concept now, and can figure out all the other stuff about interfaces as need be.

[@david-nb5ug]

I have an exam in 4 days and this video explained it better than all my lecturers. Thank you :)

[@wassimmehanna4402]

I've coding for years now in different companies. The more I know, the less I realize I know. Thanks for providing the best videos on KZbin Christopher !

[@gwho]

Best, most clear, practical illustration of the principle ever. So many books, texts, explanations are too long-winded without hitting the key point, or too high level to be useful and informative when you go to code.

[@marijkemeersman6360]

I love how you explain things. Most explanations I've seen either use no example so it stays very vague for me, or use very complicated examples with complicated code that I don't understand. You explain it so beautifully by just explaining it in general and then give an easy to understand example. Plus I'm also very fast distracted with accents and you don't have an accent that distracts me from the content :) Keep the videos coming!

[@pranjalpriyadarshi1289]

I know I am late, but this really blew my mind how you converted inheritance to composition! Awesome stuff ! Want more videos on this!

[@imankurgarg]

Thanks Chris for your videos, your real life examples are really helping in understanding the concept well. Keep walking!

[@akikohanamura4047]

Thank you for your good explanations. Really appreciate them! Looking forward to watching the design patterns series :)

[@mirianadimitrova2112]

This explanation was impeccable! It also answered the questions I had after the Strategy Pattern video :) Thank you!

[@cyantulip]

I get a lot of benefit from your videos. Your explanations are very clear, and they hit exactly those points that I find most confusing. Also, I love how you spelled "meow" with a j! That was hilarious! :D

[@anelemadonda6191]

this is the best video!!! now I can sleep in peace having learnt this. Thanks man. that errand you are running just saved me lol

[@carltonbranch5938]

Great video! I'm slowly working through them all, and many I know I'll watch more than once. Thanks from London, Ontario

[@ChristopherOkhravi]

+Carlton Branch Awesome! I'm glad to hear :) Please do ask if you have questions or comment if you want to share something. Beyond that, thanks for watching and welcome onboard :)

[@SbeveAmogus]

My English listening skill is really bad, but I still can understand every word you say. And, of course, your explanations are excellent. That's the stuff!

[@ChristopherOkhravi]

__ __ thanks! That makes me really glad :) :)

[@radu5log76]

Thank you for yet another well crafted video, beautifully explained. I have already found ways to put this to work. You have not wasted a single minute on your way to library :)

[@ChristopherOkhravi]

True that! Who wants to waste time, right :) :) :) Thank you for your encouraging words and for sharing your experience :)

[@Jackweldon12]

Your videos are the best I've found on SOLID! Great work!

[@ChristopherOkhravi]

Thanks! I'm glad it makes sense :)

[@GabeHandle]

It's like everyone else is explaining these concepts to people that already understand the concepts. Thank you for teaching the right way!

[@mohitvalechay]

thank you so much for your videos. code walks are awesome..keep walking!

[@Baroquepassion]

what I find interesting in this example (granted it's a trivial one) is that, actually, do you need the concrete animal classes? If the behaviours (strategies) are in their own class, then there's no need to have three separate animal concretions. You could just create an animal and inject in the appropriate behaviour. Which seems pretty powerful as a general concept to me. Of course, if I'd carried on listening to the end before writing my comment, I'd have got to 07:24 where he says exactly that :-)

[@praffuljavare1651]

Exactly what I thought once the code showed instantiations of cat, dog and cow. Why do we need concrete implementations if we're doing the same thing in all of them? And then my question was answered 😃

[@mojar2680]

Came here for design patters 3 months ago, coded a lot in the meanwhile, now I'm back for more =)

[@cepi24]

Sir, this is the most amazing explanation I've ever seen.Thank you. Please make longer video where you will code some "larger" IS including dbs CRUD operations and show what are some worst practices or beginner mistakes and how to fix them with SOLID and design patterns and how it will improve robustness and code quality.

[@cepi24]

PS: I really appreciate that you've explained related stuff (dependency inversion and composition over inheritance) together and do not separate them. Keep on rocking

[@cepi24]

Just to briefly sum it up. If I'm wrong correct me please: 1. Dependency Inversion - programming concept 2. Dependency Injection - implementation that allows dependency inversion 3. Constructor Injection - dependency injection implementation by passing obj1 to obj2 via obj2 constructor 4. Parameter Injection - dependency injection implementation by passing obj1 to obj2 via obj2 method (not obj2 constructor)

[@michaelmueller9635]

Helped me a lot! I was a little bit confused, cause I didnt get the difference between high- and low-level-module. And dependency inversion and dependency injection do sound the same. But they are not, they are different things. high-level-module: the inner or higher logic; like the brain low-level-modul: the outer, which does what the higher logik wants it to; like the arms, feeds being moved (by the brain to get somewhere) dependency injection (passing a externel-objects as parameters into methods of a class) implicates dependency inversion, but many people mix it up (even in tutorials)

[@stesvis]

Great explanation! I basically never user abstract classes but always interfaces, like you said at the very end

[@bermick]

why are interfaces preferred over abstract classes?

[@ievgeniiiablonsky1161]

This is great! I really like how you explain things.

[@ChristopherOkhravi]

Thank you! I'm glad it helps :) And thank you for watching :)

[@phamh79]

Thank you. I found a lot of useful information in this video.

[@michamatusiak1781]

Hi! First of all keep up the good work! Second I've got a question since you are often bringing up the term "Composition over Inheritance". I am wondering what would be the use case when one should favor inheritance?

[@anchalsrivastava3733]

Great video! A crisp and clear explanation!!

[@TheDeeStain]

Dude you're videos are mind blowing truly mind blowing

[@XTimNet]

Good Video..., good Explanation. Question: why do the Programming community call an "Extraction" process "Inversion"? This Principle should be called the Dependency Extraction Principle (DEP). I hear some people teaching this Principle say, "Sometimes this principle is hard to understand...", In my Opinion it is a very easy concept. What makes it difficult is expect to learn about how to Invert a dependency when you are actually Extracting a dependency... Words Matter. As for your video it is a very clear explanation, thank for presenting... good job :-)

[@motazabdelazeem3533]

I'm studying this principle since today morning, but "Inversion" word makes me feel that I'm still couldn't understand it, now after I found "Extraction" replacement, I could finally understood it, and now I can go to sleep :)

[@jeffruan7701]

Very true, it is not inverting anything, it is just high level and low level classes are bond by abstraction, which is basically an extraction as you pointed out

[@FabioMartignoni]

@@jeffruan7701 Try to think with an UML scheme in mind. At first, a class A instantiates and then uses an instance of a class B, so in the UML you draw a dependency arrow from A pointing at B. If you add an abstraction I, implemented by B, and inject it in A, then in the UML both A and B do have an arrow that points at I (now A high level and B low level are both depending on an abstraction), so the direction of the dependency arrows has been inverted. Of course the 'extract' work make it much easier to understand. Sorry for the bad english.

[@nancyboy7365]

The reason it is called dependency inversion is because the client and the algorithm both rely on abstractions instead of relying on each other. The advantages for this is that you never need to change up the client when you want to talk to a new class.

[@christopherkaiser1309]

Hey Christopher, Would you use DI on classes in a framework. for example in C# do you think its better to inject a Dictionary into a class or to call new Dictionary in a constructor? It seems to me the main benefit of DI is having Interfaces as parameters so you can substitute behavior. thanks.

[@CricketBugo]

Hi Chris, Nice explanation. Awesome videos!!

[@shaunhunterit342]

Thanks. This was informative and enjoyable.

[@ricardo.fontanelli]

Great video! I'm just thinking about how easy to undertand and integrate complexes classes using only constructor as DI (don't know if complex is the best term). For example a Twitter Apli Client lib, minimally you'll need a http client, a logger and a response class plus api credentials params. Yes we could use a factory or a facade to handle with that, but sometimes I think (and see loads of people doing) that could be more fluent and understandable use some base classes as default and expose setter/config methods to overrite (configure) these specific dependencies if you need/want. I mean, just to avoid that kind of libs that are too decoupled that nobody can understand how to implement it without read thousands of documentation.

[@milanliebsch6471]

You are great! I love your videos!

[@lrcleandro84]

Hi, thanks for your videos!

[@shashankpandey1019]

Awesome Great Explain!!

[@v0id_d3m0n]

Good vid! Helped me understand

[@InCircle]

Still A Well Explained Concept for me. Keep Making Videos

[@IslamIsDanger]

You bring good to the world.

[@ayasalama7533]

That was a good illustration, if someone gets distracted easily like me, Listen to chris's talk only don't watch it :'D

[@bobbuilds1403]

Great stuff!

[@simazargar]

Would you please make a video on concretion and abstraction with examples please? Thanks!

[@nayazpasha5963]

Awesome explanation Chris.. By the way, which place it is 😉

[@youtub3ian728]

it's a great way to keep attention span focused on coding while you actually keep walking in the park with trains passing by. A better idea would be to keep the coding examples up, while you walk in the park, and talk from the background.

[@MrAlkazam]

Very good and informative! Keep up the excellent work!

[@ChristopherOkhravi]

Claus Pontoppidan thanks! I'm glad it's useful :D

[@davidmuchina6180]

In other words you shouldn't weld light bulbs onto lamp holders. Systems that are subject to change (eg. A Light bulb that burns with time) should be pluggable.

[@ChristopherOkhravi]

Excellent metaphor! Thank you! 😊

[@rahulshinde6070]

Exactly same thing comes to my mind when I think of depenancy injection through interfaces.

[@kevinbenavides92]

Today I learned I've been spelling meow wrong.....

[@ChristopherOkhravi]

Hehehhe :) :) For the record I have indeed now understood that I spelled it incorrectly :) It’s how we spell it in Swedish :)

[@gwho]

This is nice, but what about when two traits have a special situation only in combination? Say you have amazon_v1_behavior (among many other versions) amazon_region_usa behavior (among many other regions) and you need something special only for v1 in combination with USA? Then the behaviors don't fit neatly into silo-ed orthogonal modules. And you end up needing conditionals in the calling code/method/object that asks about and knows about the version and region in combination. These kinds of situations arise, and when they do, is dependency inversion simply not possible/suitable?

[@jai2144]

Hi Chris this so nice explain about Dependency Inversion .....

[@ChristopherOkhravi]

+Sanjay Geeta Patidar Thanks! And thank you for watching! :)

[@SonAyoD]

Great video

[@hydtechietalks3607]

Great videos, and like the walk outside, I wish its not the code technicality, its the business scenario where this dependency injection or inversion helps would be more beneficial, for ex: My 2 cents, any injection is meant to be a variation in the business domain, Lets say Tax system - may vary as per economy conditions and reforms..so it should injectable implementation, so that core business wont have huge side effects of it... makes sense?

[@vijaykumarmanda3918]

Nice :) ThankQ

[@ZeroSleap]

So this is where one would say "If it quacks,its a duck" huh.But do the behaviours define the object?This shouldt really work for pure data classes would it?

[@FamilyGuySweden]

du är en hjälte! merci 😃

[@JavierPortillo1]

You talk about injecting through the constructor and as a parameter of a method. In what situations would you say it's better to do it in one way or the other?

[@ChristopherOkhravi]

Great question. TLDR; do you want to be able to vary the thing you inject every time you make the call or is it enough to vary it at instantiation? E.g. say that you are modeling the method `Eat()` on a class called `Animal`. Instead of hard-coding the behavior of eating in the `Animal` class (such as e.g. the units and kind of food to eat) we can construct another class, say Food and then inject an instance of Food so that the method signature becomes `Eat(Food food)`. This I would argue is dependency injection because the dependency is inverted. I.e. `Animal` does not depend on the `Food` class but rather on the "interface" of `Food`. In other words, we can feed any given animal multiple types of food as long as the food inherits from the class `Food`. This would not be possible without dependency injection. We would then have had to change the `Animal` class in order to change what type of food it eats. This is a perfect case for parameter injection. It seems sensible that the food can vary between times of eating. In other words, trying to supply the food that the animal is intended to eat at construction time (i.e. via constructor injection) seems awfully awkward. Contrast this example to e.g. something like injecting two `Wing`s to an `Airplane`. It feels intuitive to supply the wings upon construction of an airplane. Furthermore it's not absurd to argue that an airplane (it all depends on the domain ofc) should be considered an entirely new plane (i.e. a new object with new identity) if its wings are changed. Then again, the opposite could be argued, i.e. that wings should be allowed to be changed (think: repairing a plane etc.) without changing the identity of the airplane. But wanting to change wings doesn't necessarily mean that we want to vary the wings of the airplane all the time (i.e. at all method calls). So with that reasoning I would probably still inject initial wings in the constructor and then add another method to change wings using parameter injection (i.e. something like `replaceWings(ICollection wings)`. In other words, to me, the question of parameter vs constructor seems to me like a question that always needs to be looked upon in the light of your requirements. Looking at your scenario - and the way you are currently thinking about modeling your domain - do you want to be able to vary the thing you inject every time you make the call or is it enough to vary it at instantiation? Furthermore, in case you're interested in functional programming I think that constructor injection can effectively be thought of as partial application for object oriented programming. Thanks for the comment :) and apologies for the very long answer :) I hope this clears up some confusion.

[@JavierPortillo1]

Thanks a lot for your answer! I've been watching your videos and I'm really thankful for all the knowledge you have shared. It has been very difficult for me to unlearn all the bad practices I've done so carelessly and start thinking in a more general and abstract way, and your channel has helped me a lot with that. It was until last year that I started learning about OOP, and just recently I gained interest in architecture and design. Before that all I did was procedural code, huge files full of line by line instructions that did all sorts of things. I developed a lot of bad habits during that time. I feel like there's so much stuff I have to learn (and unlearn) that I don't even know where to start. If you accept my suggestion, could you please talk about your own background in your programming career. How you started, at what point you started thinking about abstractions, did you ever hit a wall in your learning curve and how did you overcome it. How did you get your first job as a developer and what have you learn from that. Thank you for all the effort you put in your videos, I really appreciate it.

[@ChristopherOkhravi]

Javier Portillo Thanks for the reply. Much appreciated. Great suggestion. Will do my best.

[@rafaeldeconde8148]

I saw that you didn't posted any new video for 6 months, I tried to figure out why, but I couldn't know why you stopped a so amazing KZbin channel, hope you're fine! But I also have a question for this video, you said near the end that if we use DI at madness, we would end up with only new keywords in the main program, you also said that a little of DI is better than no DI. Based on what you said, I understood that using DI at madness isn't actually good. I don't understand why, because for me having only new keywords in the main of my system would make easier to add new features and also would make the code more reusable.(sorry if I misunderstood what you said, but I'm new to programming and I'm trying to learn all of this design patterns and solid principles stuff )

[@ashutoshpatkar4891]

damn this was god explanation. I finally got the aha moment

[@kamelmohammad1961]

Thanks man

[@alexstone691]

doesnt this make the code totally confusing, like the classes are complex to use if you need to instatinate an behaviour every time you instantinate the object

[@mytube3486]

Nice explanation

[@justingiovanetti]

If you scale it out, for instance if there’s 100 unique behaviors of each animal, for three animals you will have 300 unique methods. What’s the difference if you have an extra three classes to wrap each of the 100 methods? Wouldn’t the extra classes simply be a nice way of packaging up and organizing all of those methods? An extra few lines of code to group hundreds of lines of methods.

[@doktoren99]

Do you know what the "inversion" word/name comes from? If i understand correctly, the inversion part is when you make the parameters abstract for example.. For example instead of a function eat() requiring grass, you could set the functions to require an abstract protocol/interface of type Vegetarian, so that when grass conforms to Vegetarian, you can send in grass or any other Vegetarian type food? Its easier to remember for me if i have something to make sense of the "inversion" word, cause i dont feel we are inverting anything, just abstracting :P Excuse my ignorance, im new. Very interesting series. Thanks.

[@masterbonzala]

*im new* .... *new* .......... TRIGGERED

[@shashankpandey1019]

Hi Chris, I m confused that why we need dependency Injection ? Can you explain some points here then its great for me.

[@marijkemeersman6360]

He says in the video that we need it to run isolated unit tests, without it, it can be hard sometimes. It also makes your code more flexible and reusable. He explains it at 2:30.

[@_javedhussain]

Great Explanation!!

[@ChristopherOkhravi]

Glad to hear. Thanks for the comment and for watching 😊😊

[@mytube3486]

@@ChristopherOkhravi when u will be back

[@ezequiasrocha3037]

I would rather prefer an in board explanation because it looks like confusing on this video. Could you do that so?

[@susmitvengurlekar]

Real life example: A worker polls a queue and executes jobs received from queue. Instead of creating an instance of a specific queue (and relying on its type, method signatures) , the worker should be passed the queue to poll and depend on the abstract Queue class and rely on the Queue class type and it's method signatures. The benefit: During development you can pass a mock queue which reads a locally stored json file of jobs. The worker code doesn't have to change. In production use AWS sqs, rabbit mq or any other real queue.

[@jiejunlin9771]

what means object-oriention 101？very cool DI!

[@exe.m1dn1ght]

King, why you don't post anymore ? Why all good things come to an end ?

[@kumaravelj4568]

No words your alien.

[@chudchadanstud]

The easiest way to explain is to use the List data structure. A List is a linear collection of data. Now imagine if you wanted a Queue. Do you a) Create a new class called Queue and write code from scratch b) Instatiate the List class inside the Queue class and just add a wrapper around the List methods you want c) Make the Queue accept a Interface that has a method called AddBack(), RemoveFront() in it's constructor and then wrap the interface methods with the appropriate queue methods? The best option is c). Why? Because your Queue is no longer dependant on the List, but its dependant on the interface or specification of that has AddBack() and RemoveFront(), (if it quarks and walks like a duck it's a duck). This means your List can be an Array, Linked List or Vector (aka dynamic array or ArrayList), etc. It doesn't matter. As long as it's a collection that allows you to add data at the back and take it out at the front, it's a Queue. The good thing about c) is that you can convert a Binary Search Tree into a queue without flatten it, if you use inorder traversal, an Adapter and an Iterator.

[@infantlightgaming4475]

What is coupling to concretion

[@JoeBonez]

Where are you walking? I wanna visit there

[@memobijou]

Dependency injection does not necessarily mean that we depend on an abstraction. With dependency injection we always separate the construction of an object of it's use. So we can inject into a class different objects of the same class but with different states. So we can say that we don't depend on an object that always has the same state on construction but instead we can inject different objects of the same class with different states. That would be an example of DI without depending on an abstraction and without inverting the dependency. However if we combine depedency injection with programming to interfaces then we depend on an abstraction and then we have inverted the dependency from it's class. Here is an example of dependency injection without depending on abstractions: class A{ String x; A(x){ this.x = x; } } class B{ A a; B(A a){ this.a = a; } } main(){ B b1 = new B(new A("object 1")); B b2 = new B(new A("object 2")); } So I would say with DI you can only invert dependencies if you use DI in combiniation with programming to interfaces. And thank you for your videos they are amazing :-)

[@GabeHandle]

Non programmers you walk by must think you're talking about some government conspiracy...

[@ChristopherOkhravi]

+Gabe Hodges Hah :D

[@eahmedshendy]

👍

[@ChristopherOkhravi]

+Ahmed Mohamed :D

[@rpo3ge]

Ain't you a god!

[@pedrolobo1081]

A cat says "Mjaaaaaaaaaaaaaauuuuuuuuuuuuu" LOL

[@jorgeromero4680]

I followed your path in Sweden more than your words lol

[@vicenzovendetta3443]

U can ask any sort of questions in the comments... Well... Are u Mr. Beans's brother? 9:16

[@shaikparvezahamad7530]

code : 4:10 5:02 6:47 6:50 8:02

[@justingiovanetti]

I think the essence of the principle is missed when using the Animal - Cat/Dog/Cow example. People inherently think of those examples as parent child relationships. The better example would be the CEO of Coca-Cola delivering sodas himself.

[@gwho]

#makeCodewalkthroughsNotAMetaphorAgain

[@jiejunlin9771]

"memeda" in chinese means :i love you !But I'm not gay!:) Thank you for great video!

[@Den-Geist-Befreien]

"mjao"

[@DrAlban22]

:D

[@SwopCovers]

No one: Swedish cats: (04:09)

[@MrKsuhiyp]

مجرم

[@1101claus]

Please, back to your whiteboard.

[@lpatrasco]

Great but... stop moving bro

[@ChristopherOkhravi]

Sorry 😊

[@Freddis]

The examples are very bad. Usually you do a really good job, but in this particular case, there’s no reason to even create dependency at the first place. The way you approach Inheritance problem actually reveals even bigger problem: people don’t fully understand why inheritance is bad. Inheritance is a great way to to shrink down the extendability and lock the behaviour (same as using private fields). DI and composition would be unlocking way to achieve that, similar to protected(+virtual). To figure that out you need to know who /what the consumers of the classes. It’s wrong to explain it on animal examples, since in that case we probably do really good with inheritance: a lot less code and room for mistakes. Imagine if cat of had the field of ‘Behavior’ type and then we can have cats barking from time to time. P.S.: To newbies. Don’t follow the rules, follow the reason why those rules exist.