0:00 Introduction 0:51 Find problem with existing code 1:36 S = Single Responsibility Principle 4:05 O = Open Extensions, Closed Modifications 7:09 L = Liskov Substitution 9:43 I = Interface Segregation 11:31 D = Dependency Inversion Great explanation with a simple to understand example. Amazing videos as always.
Experience is so freaking important!. 6 months ago, i saw this video i didnt understand anything of it. Now i understand everything! Because without knowing, i used all of this on my job, day to day on Android. Excelent! Now going for theory behind design patterns
Hi!) I am from Russia and I am learning English to find a job in another country. You have good English I understand almost everything and your videos help me to learn the language))
For Interface segregation principle; I think we shouldn't create a function (that sometimes needed and sometimes not) - printLogs() function in this video - inside the same interface, We should create another interface and declare this function in it and if we need this functionality we can implement this interface and plus other interfaces like FileLogger interface in this video
Also agree. If I have an instance of FileLogger and call printLogs(), I'd expect it to print the logs, but it won't. Moving the printLogs() to a separate interface such as LogPrinter, would make more sense.
In example for open/closed, you treated the FileLogger class as being completely closed. Your CustomFileLogger was effectively another implementation of a FileLogger interface. It is ok to add new functionality to the FileLogger class, for example adding another function called timestampedError(), as long as you do not change the logError() function it adheres to the open/closed principle. All existing consumers of FileLogger will work exactly as they did before. For your example of Liskov substitution, the CustomErrorLogger class does not violate Liskov substitution. All instances of FileLogger can be replaced with CustomErrorLogger and will work exactly the same. This is because all calls to logError() will still go to the base FileLogger via inheritance.
Your explanation is great. But, I have a question here, we already have a function named logError() in class FileLogger. So if we add timestampedError() to FileLogger it is not violating single resposibility principle? Kindly help me understand better
@@avigneswaranwaran well ... first of all timestampedError is not a good function name IMO. I follow the pattern of naming a function with a verb prefix. That, plus vonn didn't say what that function does makes it hard to know what vonn intends that function to do. But ... if that function is about logging to a file (logs a timestamped error?) then it does adhere to single responsibility (SR). Then again, vonn's comment is about Open/Closed (O/C) ... why are you asking about SR?
@@PhilippLackner I think you must do make separate interfaces for every method. So you can use multiple inheritance for every method you need. Because function with empty body standing in the interface not a good case that much.
Vielen vielen Dank lieber Philipp für diese tolle Erklärung. Du hast da wirklich ein Talent solche Dinge sehr einfach für jeden verständlich zu machen. Liebe Grüße aus Österreich.
I finally understand them now, I faced the same problem when searching them online...very hard to understand. This was waaay easier to understand. Thank you!
I watched this video after watching your multi module course. So clearly explained .. I clearly understand why you inject abstractions using hilt instead of concrete implementation ..... Thank you so much Philip
I think a more appropriate example of Liskov substitution principle would be if an overriden function were to do something unexpected and contrary to its implementation in the base class. This can be shown with a base function that changes the state of the class which is overriden by a function that doesn't call the super method. The example provided doesn't break this principle. I liked the other explanations.
After watching this last night I went back and re-watched Bob's playlist on clean code... outstanding! Then today in a long term project interview (We interview internally for projects) I was asked, 'what are the SOLID principles of good software engineering?' I played it cool, .. 'fools, little do you know Phillipp just schooled me on this shit' ... barely had the words come out of my mouth when the hiring manager said "wait you know Phillipp?" ;) Joking aside, the synchronicity is insane man, thanks so much for everything!
@@PhilippLackner Great video. I do have one doubt regarding auth in Dependency inversion. If we call auth.signInWithEmailAndPassword(), then which would be called among the functions in FirebaseAuthention and CustomApiAuthentication classes?Thanks in advance
@@satyasaineelapala570 you have to pass authenticator object while creating instance of Repository, if you've passed firebaseAuthenticator then it'll use that, and vice versa
Well done video. Just pay attention to interface segregation. Interface segregation does not mean that clients do not need to implement the entire interface. It means that you should segregate different functions under several interfaces, and then it's up to the client to decide which interfaces to implement. I don't think the example here was demonstrative of interface segregation.
Probably onClickListener and OnLongClickListener are examples of it. Those 2 could be in a single interface, but that way you would have forced the class to implement these 2 methods even you want to use either of them.
This is literally one of the best channels out there. I can’t believe that I only found it now. I love the videos. Keep them coming! P.s- would love to see a video about Alarm manager in Kotlin! Looking for such a video for a while.
Hey Phillipp we need more videos on clean architecture, if possible please make a playlist on it. I will buy that playlist if it is paid but please make that playlist
Very good video. One question regarding the Open Closed Principle: If I would create method for changing the path e.g.: open fun getPath(){...} Does this violate the principle?
For the open-closed principle, would you then be violating it if you provided a default parameter with the file path name, so that one could change the output location without extending the original class? Not sure if that's what you mean by closed to modification
On the single responsibility principle example, shouldnt the error handling part be implemented in a different class? I mean it sounds and would look weird, but in principle this class still has more than one reason to change: 1. if we want to change how the user sign-in network call is implemented 2. if we want to change how the error handling works. I mean the logging part is in another class, so if we want to change only the error logging than everything is good, but if we want to change what gets called in the catch block in the first place than the class would have two reasons to change.
Somewhere you need to catch the possible exception. I think there is no other option to handle exception like writing try-catch in the same function. If you find some solution please share that might help to understand more. Thanks
I liked explanation, Thanks! but Interface segregation principle is not explained properly. It states that, should have kept printLogs method in different interface and then can be implemented in classes wherever required.
One more question : if i add parent class as dependency in repo class and then when I create a new instance and replace parent class with child class then it will be good pratice or not??
Repo is dependent on FirebaseAuth object which is wrong, Should be asbtracted and repo should also be abstracted with separating out implementation, and separate class for logging code.
Am I crazy or did you not instantiate any of the class member objects that you are calling methods from. Still trying to get the hang of kotlin coming from java.
Do we need to remove dependency on concretion of FileLogger class? For "I" principle you can split your interface in several interfaces. Thanks for video! ❤
0:00 Introduction
0:51 Find problem with existing code
1:36 S = Single Responsibility Principle
4:05 O = Open Extensions, Closed Modifications
7:09 L = Liskov Substitution
9:43 I = Interface Segregation
11:31 D = Dependency Inversion
Great explanation with a simple to understand example. Amazing videos as always.
Vn
Vvvvvvvvv
Hv
Gvv
Ggvvv
Play the video in 2x speed then you'll be learning SOLID in 10 minutes
But you will understand 2x less as well
@@feepin2058 not necessarily
Lmao
So scary 😂
Writing code is simple but writing simple code is difficult. Good work Philip, it helped me to learn SOLID principles 😅
finally , now i understand why interfaces are so important ,I struggled so much to find reason to use them , Thank you philipp
Same here
Me too... I knew what an interface is in general, but not what it really means in coding (at least I had a bright moment)...
Experience is so freaking important!.
6 months ago, i saw this video i didnt understand anything of it.
Now i understand everything! Because without knowing, i used all of this on my job, day to day on Android.
Excelent!
Now going for theory behind design patterns
Hi!) I am from Russia and I am learning English to find a job in another country. You have good English I understand almost everything and your videos help me to learn the language))
For Interface segregation principle; I think we shouldn't create a function (that sometimes needed and sometimes not) - printLogs() function in this video - inside the same interface, We should create another interface and declare this function in it and if we need this functionality we can implement this interface and plus other interfaces like FileLogger interface in this video
Agree! But the video still is amazing.
You're right
That's what I thought. Apart from that, video was good.
Yeah! I did note that and agree with your response!
Also agree. If I have an instance of FileLogger and call printLogs(), I'd expect it to print the logs, but it won't. Moving the printLogs() to a separate interface such as LogPrinter, would make more sense.
I got goosebumps when he said, "This changes the entire implementation in one line of code. 🦋"
This is programmer porn
What a nerd 💀
The video we didn't ask for, but really needed..
I would've killed for this video when I first started learning Android and programming; Thank you.
In example for open/closed, you treated the FileLogger class as being completely closed. Your CustomFileLogger was effectively another implementation of a FileLogger interface. It is ok to add new functionality to the FileLogger class, for example adding another function called timestampedError(), as long as you do not change the logError() function it adheres to the open/closed principle. All existing consumers of FileLogger will work exactly as they did before.
For your example of Liskov substitution, the CustomErrorLogger class does not violate Liskov substitution. All instances of FileLogger can be replaced with CustomErrorLogger and will work exactly the same. This is because all calls to logError() will still go to the base FileLogger via inheritance.
Your explanation is great. But, I have a question here, we already have a function named logError() in class FileLogger. So if we add timestampedError() to FileLogger it is not violating single resposibility principle? Kindly help me understand better
@@avigneswaranwaran well ... first of all timestampedError is not a good function name IMO. I follow the pattern of naming a function with a verb prefix. That, plus vonn didn't say what that function does makes it hard to know what vonn intends that function to do. But ... if that function is about logging to a file (logs a timestamped error?) then it does adhere to single responsibility (SR). Then again, vonn's comment is about Open/Closed (O/C) ... why are you asking about SR?
This is simple AF , nobody showed this important principle with this level of simple and easy examples ! Take a bow @Philipp
For the optional interface function, you could also do = Unit instead of the empty function braces.
Yea sure was just a quick demo here
@@PhilippLackner I think you must do make separate interfaces for every method. So you can use multiple inheritance for every method you need. Because function with empty body standing in the interface not a good case that much.
Bro, you are my new superhero, much much better than any other fictional superhero
Best video about SOLID I've ever seen
Thank you for your content Philipp! It helps so much and I'm glad there are developers who strive to make code as good as possible!
Vielen vielen Dank lieber Philipp für diese tolle Erklärung. Du hast da wirklich ein Talent solche Dinge sehr einfach für jeden verständlich zu machen.
Liebe Grüße aus Österreich.
This is a most important video in the internet for devs today. It's not easy to explain this topic the way he did. Kudos @Philipp
I finally understand them now, I faced the same problem when searching them online...very hard to understand. This was waaay easier to understand. Thank you!
Glad it helped!
awesome man. I didn' like you previously when seen on interviews but Now addicted to how you teach and how humble you really are.
Been binge watching all your recent videos. Amazing Android content 👏🏽 👌🏽
You have such a nice way of explaining things brother. Keep making these videos please. Thank you.
I watched this video after watching your multi module course. So clearly explained .. I clearly understand why you inject abstractions using hilt instead of concrete implementation ..... Thank you so much Philip
This guy does it again!!! Nice explanations.
Glad you like them!
Philip God bless you soooooooo much.... i can't thank you enough
I think a more appropriate example of Liskov substitution principle would be if an overriden function were to do something unexpected and contrary to its implementation in the base class. This can be shown with a base function that changes the state of the class which is overriden by a function that doesn't call the super method. The example provided doesn't break this principle. I liked the other explanations.
After watching this last night I went back and re-watched Bob's playlist on clean code... outstanding!
Then today in a long term project interview (We interview internally for projects) I was asked, 'what are the SOLID principles of good software engineering?'
I played it cool,
.. 'fools, little do you know Phillipp just schooled me on this shit'
... barely had the words come out of my mouth when the hiring manager said "wait you know Phillipp?" ;)
Joking aside, the synchronicity is insane man, thanks so much for everything!
Haha thanks Matt! :D
The thing that I liked about the video was not wasting my time to learn this SOLID buillshit. Thanks for summarizing.
really the most informative explanation of SOLID principles. appreciated and thanks a lot man:)
You got some perfect communication skills
Thanks ❤️
@@PhilippLackner Great video. I do have one doubt regarding auth in Dependency inversion. If we call auth.signInWithEmailAndPassword(), then which would be called among the functions in FirebaseAuthention and CustomApiAuthentication classes?Thanks in advance
@@satyasaineelapala570 you have to pass authenticator object while creating instance of Repository, if you've passed firebaseAuthenticator then it'll use that, and vice versa
@@mrwhoknows Thanks
Thanks for the explanations with easy examples 👌👏
The best explanation I have ever seen. Great job
Well done video. Just pay attention to interface segregation. Interface segregation does not mean that clients do not need to implement the entire interface. It means that you should segregate different functions under several interfaces, and then it's up to the client to decide which interfaces to implement. I don't think the example here was demonstrative of interface segregation.
agreed, thanks for the feedback!
Probably onClickListener and OnLongClickListener are examples of it. Those 2 could be in a single interface, but that way you would have forced the class to implement these 2 methods even you want to use either of them.
Kudos Philip. This explanation was easy to grasp
Thankyou Philipp, your way of explaining the issues through examples is just amazing. Thankyou for this great video.
I like how you explain complex things so easy👍nice
Thank you so much dear philipp for record this courses ,
I just wanted say i love you ❤️😘
This is literally one of the best channels out there. I can’t believe that I only found it now. I love the videos. Keep them coming!
P.s- would love to see a video about Alarm manager in Kotlin! Looking for such a video for a while.
This guy is really good.... Keep it up bro
Thanks for this video man!, Big fan of your channel
Simplest and best example with clean examples just like your clean codes @Philipp ! Awesome :)
This is by far the best SOLID video explaining these complex SOLID software principles !! Thank you for this amazing content !!
Amazing video, I have studied the SOLID principles and I have never understood them so easily, congratulations, greetings from Caracas, Venezuela
Thanks a lot for that awesome explanation!
Just the thing I needed.
Surely will start using all these principles in my future projects.... Thanks bro...
Thank you so much for clear explanation of SOLID 🙏
You explain like Indians ❤ simple and easy to understand with examples.
So realy clearest explanation ever and simple practical
Thank you Philipp
Thanks mate!
Really amazing video
This is really helpful,some tutorial only targets output without considering clean code,thanks Philipp
Glad you liked it
Thank you for the explanation I learned something new today
thanks' a lot Philipp, appreciated your efforts
Finally found a Bible for SOLID.❤️🙏
Keep making such videos.👍 It truly helps a lot.😌 Thank you 🙏🙂
Thank you it was very simple and easy to understand
Hey Philipp , What about MVI pattern?Can we have any tutorial on it. Thanks
Make video on this also please Phillip
Great content. You made it clear for me. Thank you so much.
.
.
.
Thank you so much.
do you have an example of project with clean arhitecture?
Someone actually disliked this gem of a video...??! Outrageous...
Great video Philipp, would be awesome if you would cover more of these advanced topics. Keep up the good work!
Nicely and simply explained
This videos was so helpful. Thank you
Please make more videos like this !
Thanks man. Really helpful.
it is good, but I need the new version of this video ... if you have a chance to do it.
Excellent bro !
thank you mr philipp
Didn't realize I already did all of it long time ago.
Hey Phillipp we need more videos on clean architecture, if possible please make a playlist on it. I will buy that playlist if it is paid but please make that playlist
Great explanation man! Thank you!
If possible also make a video on Design Patterns 😅
Very good video. One question regarding the Open Closed Principle: If I would create method for changing the path e.g.: open fun getPath(){...} Does this violate the principle?
Thanks. Very good explanation.
Can you please make video on Important design patterns for Android developers?
Thanks in advance.
thank you very much , this is really awesome
need to watch some more time. Thanks a lot
Please Make A Series About Clean Architecture...
Perfection!
Thank you!
Well, guess I'll be here for the rest of my college, bout to dive head first into android dev.
great material, very helpful, thanks !
I always enjoy your videos. Would u do one video on adding time and date in an android studio app
Thanks I do that in a bunch of my Playlists
Thanks philipp
Hi Philipp.... Could you please do a video on How to use Ktor on an Android client...
For the open-closed principle, would you then be violating it if you provided a default parameter with the file path name, so that one could change the output location without extending the original class? Not sure if that's what you mean by closed to modification
Really awesome explanation 😐😐👏
Thanks bro!
On the single responsibility principle example, shouldnt the error handling part be implemented in a different class? I mean it sounds and would look weird, but in principle this class still has more than one reason to change: 1. if we want to change how the user sign-in network call is implemented 2. if we want to change how the error handling works. I mean the logging part is in another class, so if we want to change only the error logging than everything is good, but if we want to change what gets called in the catch block in the first place than the class would have two reasons to change.
Somewhere you need to catch the possible exception. I think there is no other option to handle exception like writing try-catch in the same function. If you find some solution please share that might help to understand more. Thanks
I liked explanation, Thanks! but Interface segregation principle is not explained properly. It states that, should have kept printLogs method in different interface and then can be implemented in classes wherever required.
Awesome video!!
For liskov princple you can replace the filelogger with custum logger class
Sure you could but it won't work how a file logger is intended to work
@@PhilippLackner no i am saying in repo class? Will it ne good or bad
I am always confused with interface and inheritance class
@@HasanKhan-ol2no no that's bad because then you couldn't replace it with another logger. You're forced to pass the custom one
One more question : if i add parent class as dependency in repo class and then when I create a new instance and replace parent class with child class then it will be good pratice or not??
1:36 A module should be responsible to one, and only one, actor. © Uncle Bob
Sir, u are the best!
Repo is dependent on FirebaseAuth object which is wrong, Should be asbtracted and repo should also be abstracted with separating out implementation, and separate class for logging code.
Am I crazy or did you not instantiate any of the class member objects that you are calling methods from. Still trying to get the hang of kotlin coming from java.
Brilliant content
Do we need to remove dependency on concretion of FileLogger class?
For "I" principle you can split your interface in several interfaces.
Thanks for video! ❤
is there somewhere that you put this code? thanks!
Superb!!
thanks, it looks very easy to understand. Do you have any video about customizing views in android?
Only in compose
Can you please make medium scale app with clean architecture so we can practice on it.
Please make video on things we do wrong, without even knowing it.
Its good to see the stuff I usually do put into a list.. notice I said USUALLY hehe