Dependency Inversion Principle Explained - SOLID Design Principles 

I have mentored Jr. Developers and wanted to share my experience. Teaching SOLID too early doesn't work because the coder doesn't have the painful memories that mentally reinforce / accurately quantify the value of SOLID. The same goes for recognizing code smells. A Jr Developer is often just pleased with producing a result that works because that's what yielded a good mark in school. (CS degree is a joke IMO. Its like teaching just enough chemistry to make bombs without any safety training)

@@skewty ++. Let juniors be juniors so they can become good seniors

​@@danielmcgrane8608I am happy to read your comments. If dependency inversion is not for juniors then I am leveling up. (:

Does it really matter what language it is? Just gotta use your imagination to connect the dots and adapt it to your language of choice.

i think this is code language agnostic,

@@brianbitchballs3902 some guys need examples to understand.

@@zuzukouzina-original for concepts its better to learn UML which can help you disassociate your self from languages , and focus on understanding concrete ideas not examples

TS is just JS with types...

Yeah the name is pretty bad, it implies Stripe/PayPal depends on store which doesn't make sense. The concept itself is brilliant though.

Thank you so much!

Some people might legit not like this video. But also a lot of bots dislike videos to appear like real users. When you "buy likes" from an underground service they will spam likes to the video you want, but to appear like they are not bots they will also dislike random videos (to make it seem like it is just organic traffic).

This is dependency inversion principle

This is dependency inversion principle

That violates OCP

No, you want some interface or set of interfaces for the payment processing, like an abstract class for the Payment Processor, and possibly using something like the Strategy Pattern, to make your concrete Payment Processors. Then you can use the Strategy Pattern to just swap out between different PaymentProcessors easily.

You are very welcome!

SOLID is Single responsibility Open close principle Liskov substitution principle Interface Dependency injection Richard Martin's said that the S and the O can be join together and create a Dependency inversion principle. So in shorter words, they are the same

@@nandomax3 dependency injection is not a principle. Dependency inversion is the fifth principle. Dependency injection is an implementation

@@vittoriomorellini1939 it's funny, because I posted this a year ago and just learned about spring DI implementation this month hahahaha

normal js doesn't but typescript do, and its almost the same as js but you can use int, float, etc..

I don't know what is to depend anymore. Or maybe it's that the word is ambiguous at times.

@@FG-qs8uj If you want to know more why DI is so important in large scale application. try to search up Clean Architecture by Uncle Bob. It's just the same as SOLID principle. If you're not happy with OOP. then youi can always go back to Functional Programming.

If you read what you wrote: We don't want to depend X to Y. We want Y to depend X. X is application, Y Is framework. Wouldn't be better: We don't want X to depend on Y. We want Y to depend on X? Or: We don't want Y as a dependency of X We want X as a dependency of Y. In any case, my point is that saying X depends on Y is more intuitive to me. I.e. an application depends on a framework to work, i.e. if you see the application requirements file you would see the framework mentioned. The other way, Y depends on X. Meaning the framework depending on the application is not intuitive to me, since the framework doesn't need the application to work. I suppose then that the semantics of 'depend' and derivative words is what is confusing. And even then, I don't see the point on discussing Y depending on X Vs X depending on Y. At the end I don't see what changes in the code.

The point of this code is so that we can decouple the API we use and the store from each other. Now our store only depends on the processor wrapper we created so we can freely change our API of choice by just creating a new wrapper to wrap that API and our store stays exactly the same. If we tried to make one payment processor that handled all the APIs then we would be violating other SOLID principles such as Open/Closed.

@@WebDevSimplified i didn't hear yet about that open/closed principles. Thank you for explanation and for all your short but effective lessons 👍

JavaScript doesn’t support interfaces unfortunately. That’s why I kinda wish he would’ve made these videos in typescript

yes, solid principles apply even to non-OOP paradigms like functional programming

yes, you can make an interface class, then create classes that implement the methods

a base PaymentProfessor interface that enforces makePayment() method is a good idea, since it is reasonable to assume that all payment methods will make payment, so other the substitute principle is satisfied also.

You are very welcome!

Coupling is only bad in one direction. Also don't couple high level business code / computation code with low level data storage / access code. Uncle Bob is probably the most famous SOLID guy. Checkout some of his videos if you are interested in further developing your understanding of SOLID.

Unless you use something like TypeScript you cannot guarantee this. It is just something you need to know when developing the code.

You could write unit tests that verify certain functions exist on both

Simple version: Check that the pay method exists before setting this.paymentProcessor. if (typeof paymentProcessor.pay !== "function") { throw new Error('Store.paymentProcessor requires method pay ' ) } Sophisticated version: Create a NullPaymentProcessor class that contains the required methods, but they throw a descriptive error (or handle the exception some other way, depending on your implementation) , then make StripePaymentProcessor and PayPalPaymentProcessor extend the NullPaymentProcessor class. class NullPaymentProcessor { pay() { throw new Error(`No pay method defined in ${this.constructor.name}. pay is a required method`) } otherMethod() { throw new Error(`No otherMethod defined in ${this.constructor.name}. otherMethod is a required method`) } } class StripePaymentProcessor extends NullPaymentProcessor { constructor(user) { super() this.stripe = new Stripe(user) } } class Store { constructor(paymentProcessor) { this.paymentProcessor = paymentProcessor } purchaseBike(quantity) { this.paymentProcessor.pay(200 * quantity) } } const store = new Store(new StripePaymentProcessor('John')) store.purchaseBike(1) output -> No pay method defined in StripePaymentProcessor. pay is a required method More or less, use the null object design pattern to implement an interface in javascript. Kyle, would you agree with this approach?

thats what I was thinking. The paymentProccesor could implement a strategy pattern right? Which keeps it all clean and simple

This is exactly what I was thinking. Programming without interfaces always looks so cumbersome. This could have been resolved in a much simpler way with an interface.

Hmmm not sure! Dependency inversion is a type of dependency injection. What is special about this kind of DI is that you do not declare in any moment what concretion will be used inside the high level classes, it leaves it to the client code in which the high level class will be instantiated. Not any dependency injection works like that, after all it's possible to design a dependency injection declaring a low level class inside a high level class, which violates the dependency injection principle, making the high level class get to meet the low level class, generating coupling.

Dependency Inversion is a form of abstraction, but not all forms of abstractions are Dependency Inversion. Basically, you use DI when you're implementing something that can be done in multiple different ways and you may need to change/support other ways in the future. Besides the Payment Processor example in the video, another example would be if your app had a "share to social media" feature. Say you only wanted to have an option to share to facebook now. You could make a facebook class & shareToFacebook() method that shares your content to only facebook. But now if you decide to add options to share to twitter or instagram later, you're going to have to edit multiple places in your code base to support this. Now imagine if instead of creating a facebook class & shareToFacebook() method, you created a SocialMedia class and a generic share method that can be passed in a specific type of social media. Now you only have to extend the SocialMedia class to support twitter, instagram, etc and you don't have to go and edit your whole code base like you would in the facebook class example. Hope this makes sense, good luck!

I have thought about it but I am a bad and slow writer my weekly blog posts already take me a really long time to write compared to most people.

@@WebDevSimplified Your videos are still awesome and "simplified" :) keep them coming. Video suggestion: A JavaScript learning roadmap which gets more complex the more you advance (Junior, mid-level and senior). As most roadmaps out there focus more on the web-dev path in terms of tools and technologies, but non goes in depth in terms of the language itself and CS concepts.

@@WebDevSimplified Slow and steady wins the race........

Great idea. I will for sure add this to my list.

Depends on the kind of software you write, sometimes it's very useful. It also facilitates decoupling which can reduce build time in compiled languages and makes it easier to unit test your modules separately which is in my opinion the real reason to do this.