Low Level Design 109 | Dependency Inversion Principle | 2022 | System Design

[@sagarnikam8001]

When we implement a class at lowerlevel without using interfaces you explained(in cacheStore example) that the higher level class needs to be changed when we change the signature (number of variables) of some function inside low-level class... How using interfaces will solve this issue? I mean if we change signature of function in interface then we also need to make changes in higher-level classes and lower-level class...

[@litcode702]

I am searching answer for the same question but did not get it yet......others please like sagar's comment so that she sees it.

[@talib7508]

Same dought😄

[@vibhavaribellutagi9738]

I have the same question!!

[@balakrishnabilla]

I think the idea is to explain changes in the implementations not the signature in future wouldn't impact the high-level module....

[@sagarnikam8001]

@@balakrishnabilla how changes in low level classes will affect high level module and how introducing interface will solve that?

[@AjeetKumar-wx9ms]

at 6:33, should the implementation in UserProfile be "CacheStore createCacheService = new CreateCacheService();"? Otherwise, your code still has the context of concrete class when you are calling the addKey()

[@sridharaddagatla]

Yup, It should be `Interface objName = new ObjectClass()`. I dont think we can instantiate an interface(it doesn't make any sense to instantiate an interface).

[@nitish0194]

Yeah seems like it. I was trying to implement her code solutions in C#, and when I reached to this line, I knew it should be "Interface objectName = new ClassWhichImplementsInterface();" But then I doubted myself LOL. Maybe the author needs to change this. I wonder why her IDE did not throw an error because Visual Studio immediately said NOOOOOOOO

[@Akash.B28]

I even just by looking her code I too felt the same​@@nitish0194

[@jamestacular]

So for the example above, what if your two implementations require different parameters? For example the CacheStore.AddKey() in your new implementation takes an integer value instead of a string value? You could make a new method called AddKeyInt() but that would break the Interface Segregation principle because the first class wouldn't have a need for the new method

[@manojr40]

seriously she explains soo clearly with example! She must run a tutor!

[@unicornpenguin7]

I see there are many comments requiring clarity on this. Hope this scenario helps. If one wants to simplify Dependency Inversion principle (DIP) a bit too much then one can say that High Level classes should not depend on Low Level Classes (i.e Actual Implementation) but on Abstraction (i.e Interfaces). Why you may ask ? Because let's say without DIP, if say one needs to change something about Low Level Class being used in High Level Class, then High Level class is modified. Classic example would be say a Class called DataPersistance was using a class to save data to sql server via SQLStore and say now we have a case where we want it to change to NoSQLStore for certain cases (achieved via run time polymorphism), then we will have to change the implementation in the DataPersistance. A good design would have an Interface named DataStore which will have two implementations SQLStore, NoSQLStore (since methods like add, delete would be identical so common interface makes sense). This interface would be injected to DataPersistance class and now say in future you want to add new store, then all you need is implementing that store from the same DataStore interface. This helps to achieve following things :- 1. No code changes directly in high level classes. (Interface instantiation is already decoupled from High Level classes. Example using Spring IOC) 2. No side effects therefore from changed Low Level Implementation in existing workflows.

[@priyankaagrawal3004]

Good explanation overall but the example for cache doesn't look right. The main reason for moving to interface is: 1. Remove tight coupling of concrete implementation of cache service (which may change) and we only want to depend on the general cache interface 2. Ease of testing - Now I don't need to initialize the concrete implementation of cache service for testing the Class which has dependency on concrete cache service

[@MixedPlatter]

Hi Arpita, Open close Principal have you discussed in any of your video? I might have missed that!

[@mrunankmistry7255]

Very well explained! Really appreciate the concise quality content! Graphics are great as well.

[@vineethareddy5434]

6:15 it should've been CacheStore cacheStoreService = new CacheStoreService(); instead of new CacheStore()

[@jokhakararpan31]

Exactly my thought, but I am from Javascript background so thould my understanding was wrong.

[@mitanshukr]

correct 💯

[@mohannani2025]

Yes correct

[@shivangpatel]

Please correct it. Low Level Design 109 | Dependency Inversion Principle | 2022 | System Design ---- Otherwise all contents are very good and explain very well. Thank you.

[@csatmathematicsforupscandc3661]

+1 this video is bullshit and misleading @Sudocode

[@RICHARDKALIMJR]

ang galing mo talaga mag turo Hon. Leni Robredo 🇵🇭

[@nabhavlogs371]

in the example given above, even if I want to add support for multiple data stores, I dont need to change the method signature of any of the above methods, even if I dont use dependency inversion. and even i method signature has to be changed, it has to be changed in interface as well.

[@altonlebronze3536]

Great explanation. The only exception to this principle are the utility classes that only contain static methods. For example when your program (high level module) calls Integer.parseInt(String str), there is no interface

[@jasper5016]

Hi Arpita, thanks for this fantastic video. Is the code @6.10 correct? CacheStoreService cacheStoreService = new CacheStore(); Should not be it other way? You cannot create an instance of Interface. CacheStore cacheStore = new CacheStoreService();

[@AtulKumar-bi8qq]

I am also struggling with the same question 🤣

[@aneesbazmi1612]

@@AtulKumar-bi8qq what if the signatures needs to be changed in Interface, then it will impact the whole code what do you say?

[@iamhb1006]

6:13 i think it’s wrong, you can’t create object of abstract class/ interface. So in UserProfile it is written incorrectly.

[@shriharisambath3831]

Please explain Open Close as well, your explanation is very layman and helpful, Thanks

[@akshay-kumar-007]

open-closed principle is the most open ended principle of te 5 SOLID principles. It basically says that you should not make changes(modify) current implementation if we want to extend or add new functionality of our application. open for extension, closed for modification. Open closed principle is implemented automatically, if we implement single responsibility principle and dependency inversion principle.

[@tusharu9107]

All your videos on solid design principles are really good and easy to understand. Only open/close principle is missing from the series, eagerly waiting for open/close principle video.

[@ninonazgaidze1360]

The best videos I've seen about SOLID principles

[@bhushanpoorkar8482]

Where is the video for Open Close Principle :-) u missed it?

[@qushiexpressionqueen6535]

I think abstraction can implement using both interface and abstract class not only interface. over all u explained DIP Principle nicely. Thank u.

[@kalyanroy6687]

Please do make a video on Dependency Injection and Inversion of Control. These are easy confusable .

[@HariSarvotama]

but how does it change anything in this given example? if we change the implementation by changing the variables as you mentioned , then we still need to change in the interface right , so how does it actually help by having the interface. I'm sure the concept is right but the example given here is wrong .

[@AbhishekKumar-yv6ih]

Yes. Same doubt

[@sudocode]

Changing the variable of implementation classes and not interfaces.

[@HariSarvotama]

Do you mean creating a new method in class and giving new parameters requirements in the client?

[@seeker4430]

Could you please make videos on Dependency Injection and inversion of control also

[@vipinmv2431]

Probably the most simplest explanation on this topic....Thank you.

[@sisirreddy6385]

I am big fan of yours tutorials. The way you explained is awesome. I want to know when we need to change signature of the method we need to change interface signature too. How DI solve this issue.

[@DhananjaySingh-po2uc]

I too have same doubt . In the example signatures were not changed :(

[@digvijaychauhan7312]

Expecting more videos. As I got a clear understanding of simple words and examples. Great work. Keep growing.

[@sukanta_nandi]

Can you create a video about the difference between inversion control and dependency Inversion

[@balkrishnatalele3408]

You talked about add Key and said if parameter changes or signature change and then you are adding interface. What if interface changes just like signature. Still there is problem.

[@Almostgod12]

One think like to add. if if you are mocking B you don't need to mock A.

[@deepakp2936]

Hi Yogita, I like your video's. Can you add video for Open Close Principal? Shouldn't the title be ""Low Level Design 109"?

[@sudocode]

Yes. That video was recorded but we felt that it needd to be re-recorded. We will upload it soon.

[@AliTheHondaBoii]

I subscribed amazing high level knowledge and explained very well, thank you!!

[@techworld7765]

In the first example you said that if we want to change the signature then dependency on concrete will be a problem but that problem will be there even if interface dependency is also there and that's why for interface dependency you changed the example to implementation of concrete class and I dont see any problem in concrete class dependency even if it's implementation is changed only as per the example you gave, sorry but can't see the benefit of using interface in your example

[@walecharohit]

yes right..these useless principles are teaching us what we already know and can learn by writing code and continously maintaining it..these are just theories which interviewer's use to present themseleves like they are the inventors of computer science.."theory is not enough"

[@SachinKumar-ml1hn]

Can someone help me with the actual code preferably in Java of removing dependency of class to class B through interface?

[@mishudas8113]

When we need a parameter in addkey function, we need to change the interface as well as in its implementations. But you said no need to change when interfaces are created. Can you explain this?

[@ishanarora7948]

Yes same here even I have this doubt

[@abisheksoni3354]

Thanks for wonderful content. Would like to hear from you about dependency injection vs invesrion vs invesrion control

[@gokulsrinivasan8563]

Hi , Open Close principle is not covered in this. Kindly add it also

[@samlobo1234]

Not clear. The problem you have mentioned and the solution as interface you have given is not in sync. For example, let say interfaceA has two functions which was impl by class B, now interface again need to change to add another 3 functions, this is impacting class B anyhow as it must impl those new three functions too.

[@abhishekmishra3957]

Nice video, eagerly waiting for design patterns video.

[@rohanmahapatra6269]

good explanation. Kind of wierd how most of the SOLID principles are mostly just using interfaces/abstractions and de-couple the components. BTW who is arpit 🤣🤣

[@princedey8270]

please, make content on abstraction and encapsulation

[@vivekchaudhary1768]

Please share the book name for design patterns

[@sudocode]

It's in the description Vivek.

[@sallaklamhayyen9876]

thank you so much

[@SanjayJain-uo3pe]

That seems to be a bad example , either way , if it is via interface or directly from class , if the variables while calling func is same , then whether or not the implementation changes , it doesnt affect the higher level modules , we are still calling the same function the same way , underlying code may change , no need for interfaces in this.

[@upendrasingh5371]

open close principle is missing

[@NishantChauhan116]

It is not explained correctly in the video as if the number of parameters changes, the interface can't help. And if cache technology changes, an interface is not needed. So, in both the cases we can proceed without an interface.

[@sudocode]

Please read a book first.

[@hemantsingh3607]

if I completed ms degree from Georgia tech University can I get 40000 job in India or abroad . Please tell me am in the second year of the BCA bachelor of computer education from mdsu University of Ajmer

[@amitkhaware290]

Open-Close Principle is missing

[@PkSam07]

I think explanation not good this time. I think using factory pattern is the inversion principle. If suppose need to make changes in instantiation logic of any object in future then can make changes in factory only instead of making changes in each and every places where this object being used via new operator.

[@unicornpenguin7]

Yes that is true. Solid principles are principles and not implementations. Factory pattern is more than just inversion principle. It is also used when follow Open Close principle. If one wants to simplify Dependency Inversion principle (DIP) a bit too much then one can say that High Level classes should not depend on Low Level Classes (i.e Actual Implementation) but on Abstraction (i.e Interfaces). Why you may ask ? Because let's say without DIP, if say one needs to change something about Low Level Class being used in High Level Class, then High Level class is modified. Classic example would be say a Class called DataPersistance was using a class to save data to sql server via SQLStore and say now we have a case where we want it to change to NoSQLStore for certain cases (achieved via run time polymorphism), then we will have to change the implementation in the DataPersistance. A good design would have an Interface named DataStore which will have two implementations SQLStore, NoSQLStore (since methods like add, delete would be identical so common interface makes sense). This interface would be injected to DataPersistance class and now say in future you want to add new store, then all you need is implementing that store from the same DataStore interface. This helps to achieve following things :- 1. No code changes directly in high level classes. (Interface instantiation is already decoupled from High Level classes. Example using Spring IOC) 2. No side effects therefore from changed Low Level Implementation in existing workflows. To answer more on Factory pattern, apart from that, it is used in Template Design Pattern. Also Abstract Factory and Prototype Pattern do use it as well. Hope this helps.

[@wanderingfido]

"This mind intentionally left blank." --Me

[@SantoshKumar-bu2qr]

Amazing hardwork and infographic but terrible example :(