Design Patterns: Dependency Inversion Principle Explained Practically in C# (The D in SOLID)

When you are writing code, are you doing it right? That is a question that worries a lot of people, and it should probably at least be something every developer thinks through. Design patterns are best-practice concepts that we can implement into our code to make it better in some way. Think of them as guardrails that keep our code safe. In this video, we are going to look at the fifth entry in the famous SOLID principle. The D stands for Dependency Inversion Principle. This is not the same thing as Dependency Injection, but it is what powers it.

0:00 - Intro
1:43 - Demo code walk-through
4:40 - Dependency Inversion Principle: DI Explained
7:42 - Implementing DI: Demo code refactoring
26:15 - Benefits of DI: Changing the code
27:18 - Benefits of DI: Modular code
29:10 - Benefits of DI: Dependency injection
33:03 - Benefits of DI: Unit testing
37:32 - Summary and concluding remarks

[JamCram]

These are the best series on SOLID in youtube. Thanks a lot.

[shawnmofid]

There is no replacement for video content and this type of platform. You get to watch it any time, any where, and as many times as you want to and you can. So glad to be alive in this time and age. Thanks for the content Tim. I leaned a lot.

[nytofteAS]

I have been taught here and there about the SOLID principles for over a year now. This seems to be the first time that I have really grasped these concepts completely and now also know how to use them. Thank you and great material in general.

[liferide]

Dependency inversion is the principle; dependency injection is one way of making the principle work. - I love you man

[brendonanderson]

I actually finally understand abstract classes, interfaces and their purpose. This SOLID series helped me a lot!

[Funkfreed]

My eyes lit up while watching this! 3 years ago a small company on a conglomerate project we had went live. They were using an automation approval tool that didn't allow much programming but had all the tools i.e. API call, SQL, WS, message builder etc. They were so dependent on this that the business logic was built into each approval flows. We had to do a lot of code changes every time the approval level change. I eventually had to implement a matrix table where all the approval flows adhere to. It made the application dynamic and they can control it however they want as long as they follow certain rules(like the interface).

It's funny how this principle can be implemented on many other platforms. I think ServiceMesh also has the same concept. You have a lot of containers and they all follow a certain set of rules and all reports back to the command center.

Thanks Tim for this wonderful lesson! As always you untangle the complication of many programming concepts. God bless you!

[femloh]

By far the best explanation I have seen on dependency inversion. Thank you.

[johnpintocarvajal]

Tim, at first when I saw the length of any of your videos, I thought "oh man...."; but now I know for sure that those 40-60 min are enough to get away with the concept and how it looks in real life/in real code... instead of spending that same hour (probably a lot more) going the hard way: digging on the internet trying to clarify any given concept.
Just go straight ahead to Tim's channel and enjoy the explanation of such a wonderful teacher.

Thanks for all the awesome and comprehensive content you make!

[mralex]

Man, I watched these videos as an experienced developer, I almost didn't learn something new.
BUT I'm so amazed at your skills to explain things in such an interesting and ordered manner. I couldn't stop watching you.
I'm so amazed that such quality content is available for free here.
Thanks, man, you're doing a gorgeous job, hope more people will see these vids.

[eCoderIE]

You're awesome, years in the industry and i always thought Dependency Injection was same as Dependency Inversion. Thank you.

[heinzeckner]

After numerous videos and blogs, I understood for the first time how easy a factory method can be and where it can be placed. Most authors can or just want to explain it abstractly and academically - but you got to the point. Thanks a lot! ... An open question for me is whether the factory class from your specific example now violates the SRP principle... That's where it's going to be confusing to me all the time in OOP (coming from 15 years of procedural languages). Though I am firmly convinced and excited about the superiority of OOP - sometimes all that conventions/patterns seems to a large extent being busy clearing a lot of stuff from the living room into the kitchen and the hallway - only to conclude that at the end I am mostly in the living room and need most of the things right there :-)

[x]

Hi Tim, Thank you very much for this wonderful session. Here's my summary and understanding after practicing the demo project:
Dependency inversion states that the higher-level modules should not depend on the lower-level module, but rather both should depend on abstraction, and those abstraction should not depend on details. Basically, what this means is, higher-level modules should not create objects of the lower-level modules (classes). This responsibility should be assigned to new class (this class (Factory.cs) takes care of the object creation). The higher-level module classes should implement interface to seperate the implementation. The advantage of this is - if a new class (texter.cs) is addedd in the future to the project, the change is only done at the Factory.cs and does not impact the other files (classes).
The abstraction should not depend on the details.. the interfaces and Factory.cs does not depend on detail, the implementation is done by the classes that implement these interfaces, Factory.cs only job is to create the objects.
I hope this understanding is correct?

[adamlasry]

The best C# teacher in the world! And I really mean it. Thank you so much, sir! Brilliant teacher!

[princeonukwili]

Thank you Mr.Tim. You're like a father and a mentor to most developers out there, and a grandpa to newbies😂. I really learnt a lot. What brought me here is your tutorial on Dapper and minimal APIs where I asked why you created interfaces for each of the classes, and you replied because of Dependency injection. Since then I've been curious and I'm glad I finally got an answer. Thank you again sir. May God bless you in Jesus Christ name. Amen😌.

[dannylaza]

These videos really helped me. I always thought I was a good programmer. When I actually got a real job, I see my company implements all this stuff and I was confused on why I kept seeing all these interfaces everywhere. It's mind blowing I didn't know this sooner. This last video is especially amazing. Thanks Tim.

[Velreine]

I just started looking at Design Patterns not more than a few weeks ago, even bought a course on Udemy.

What are the odds that the best guy to explain complex principles comes in to rescue the day, just as I'm about to learn all this stuff.

Thanks for these videos they are great.

[jaminbenjamin]

Finished with your SOLID videos and a few others about interfaces and generics. The way you SHOW the reasons to use SOLID and the fact that your examples are very similar to real life situations....it makes the content very easy to understand and retain in my mind. Can't thank you enough, I'm gonna watch ALL of your videos!

[colinmikolajczak]

Hey, you're videos are amazing. I am actually a computer scientist and know all this but i love to watch your videos since they're of really high quality. I'm sure you're helping a lot of people with this kind of content and the way you're presenting it.

[nickfotopoulos]

I learned more from this short video than I did in weeks of browsing and reading on the topic.

[Napkinholdin]

OMG I watched only this one in the SOLID series and my mind is -blown-
This is exactly how I always thought programming was supposed to be like but my formal education did not go over SOLID, I didn't even know it existed... Thank you so much!! <3
Now I need to go watch the rest of the videos!