Interesting and informative. I've used enums many times in my code, but now I see using an interface with classes implementing it would have been a better choice in many situations. I would just change one thing in the Liskov Substitution Principle example: Seeing specific Video member variables like title, likes and views under a class named VideoManager seems wrong to me. Instead, I would have left these member variables under the Video class and move the playRandomAd() method to VideoManager. PremiumVideo would still inherit from Video. That way, you also remove the need to duplicate the getNumbersOfHoursPlayed() in every subclass.
Thank you :) Yup, well done! Why not, that is another way of doing it! This video is about the 'what' and not the 'how', we are just demonstrating what these principles are, feel free to implement them however you see fit!
thank you, I am always struggling with that in high level applications. The part with Dependency Inversion Principle helped me alot, well can you do a example with best practices lets say with have 5 moduls?
Thank you! Glad to be of help :) There are no specific channels, I just try to see as many references as I can before making a video to add on top of the stuff I already know.
The solution in Liskov substitution principle with VideoManager breaks the Single Responsibility Principle, now one class is responsible for two totally different behaviors.
I am reading Clean Code and one thing I noticed is that Robert C. Martin recommends to avoid words like manager, processor, data or info in the names of a class, i.e. VideoManager at 7:14
These videos are extremely helpful, they deserve much more views. You are amazing! One question, doesn't the VideoManager class (at 7:16) violate the Single Responsibility Principle? I'm really not sure, it just seems a little strange. Does "managing a video" count as a single responsibility? Isn't that a bit too broad?
Thanks a lot! Since we are focusing in each part on one single principle and diving in its details, it won't be the cleanest way to actually solve the problem, but we can't explain them independently without doing that! So, yes, feel free to tear it apart and implement multiple specific interfaces :)
In Liskov's substitution is same to say: replace the child by its father or replace the father by its child? I see both ideas explaining this principle on the web
Very nice tutorial. Have a question tho regarding L. You will not be able to have a single collection of all videos now, or am I missing something here ?
Thanks! In this example yes, because we are focusing on one principle at one point in time. However, you should strive on keeping all of them in check, so the best practice would be to have specific interfaces implemented by the videos and use these instead.
The principles state what the problem is but not the solution. So, you can use whatever means necessary to resolve them. Sometimes, creating specific interfaces could resolve this issue. In this video, we tried to explore different way to do that as much as possible! Cheers!
First time as a student that I completly understand SOLID principles ! Thanks for the share.
This video is amazing. Your channel is underrated, you're great at teaching
Thank you so much :) I really appreciate it!
Interesting and informative. I've used enums many times in my code, but now I see using an interface with classes implementing it would have been a better choice in many situations.
I would just change one thing in the Liskov Substitution Principle example:
Seeing specific Video member variables like title, likes and views under a class named VideoManager seems wrong to me. Instead, I would have left these member variables under the Video class and move the playRandomAd() method to VideoManager.
PremiumVideo would still inherit from Video. That way, you also remove the need to duplicate the getNumbersOfHoursPlayed() in every subclass.
Thank you :) Yup, well done! Why not, that is another way of doing it! This video is about the 'what' and not the 'how', we are just demonstrating what these principles are, feel free to implement them however you see fit!
And what will happened if I then invoke new PremiumVideo.playRandomAd() - the method of the base class?
Your videos clear all my doubts. Thanks
Best video I have ever seen on SOLID design principles!
best and straightforward video I have watched on this topic. Thanks you
Perfectly explained in 11 minutes! Thanks!
This is an amazing video. Very easy to understand with examples. Please keep it up!
Glad you liked it! More incoming... Stay Tuned :)
Agreed!! First time I really get all principles after a decade
thank you, I am always struggling with that in high level applications. The part with Dependency Inversion Principle helped me alot, well can you do a example with best practices lets say with have 5 moduls?
Glad it did! Will add it to my list of upcoming video, stay tuned!
You are God sent. Great content. Kindly recommend other channels that teach the way you do.
Thank you! Glad to be of help :) There are no specific channels, I just try to see as many references as I can before making a video to add on top of the stuff I already know.
The solution in Liskov substitution principle with VideoManager breaks the Single Responsibility Principle, now one class is responsible for two totally different behaviors.
Underrated channel . Like and shared. Thanks a lot for the efforts🙏
Thanks for the support :)
I am reading Clean Code and one thing I noticed is that Robert C. Martin recommends to avoid words like manager, processor, data or info in the names of a class, i.e. VideoManager at 7:14
but to be honest I have no idea what else to name it in this case
Underrated great explanation
Excellent video
These videos are extremely helpful, they deserve much more views. You are amazing!
One question, doesn't the VideoManager class (at 7:16) violate the Single Responsibility Principle? I'm really not sure, it just seems a little strange. Does "managing a video" count as a single responsibility? Isn't that a bit too broad?
Thanks a lot! Since we are focusing in each part on one single principle and diving in its details, it won't be the cleanest way to actually solve the problem, but we can't explain them independently without doing that! So, yes, feel free to tear it apart and implement multiple specific interfaces :)
@@geekific Thank you for the answer! :)
The most underrated channel ever!
In Liskov's substitution is same to say: replace the child by its father or replace the father by its child? I see both ideas explaining this principle on the web
Very well explained..❤
Super incredible, I enjoyed every single second
Glad you enjoyed it! Happy to help :)
Really excellent! Thank you!
perfectly explained
Thanks for the video. Came up with a question. Is the VideoManager class in Liskov's Substitution Principle not violating SRP?
wow this video was beautifully made.
isn't the Liskov substitution principle the opposite of what shown in the video? i.e. Base type should be replaceable by the sub type?
@@geekific OP is right, the text needs fixing, you got it the other way around. ;)
LSP is not updated yet with example Base type replace by sub type...
Super helpful
Thank you❤
Absoloutly superb explanation! Thanx!!!
Glad it was helpful! You're welcome :)
Very nice tutorial. Have a question tho regarding L. You will not be able to have a single collection of all videos now, or am I missing something here ?
Thanks! In this example yes, because we are focusing on one principle at one point in time. However, you should strive on keeping all of them in check, so the best practice would be to have specific interfaces implemented by the videos and use these instead.
i am d'accord@@geekific
good refresher
Great video with great examples and explanation!
Thank you :) Glad you liked it!
Thanks sir, it's very clear
Is it possible for your to show us how to write clean or secure Java Springboot code? especially leveraging design patterns.
Of course, and it is actually in the making, will be uploaded in the SpringBoot playlist, don't have an exact timeline, but it will! Stay Tuned!
thanks you@@geekific
Does the Liskov principle always mean applying composition?
The principles state what the problem is but not the solution. So, you can use whatever means necessary to resolve them. Sometimes, creating specific interfaces could resolve this issue. In this video, we tried to explore different way to do that as much as possible! Cheers!
Thanks a lot for the fast reply also Happy new year to you bro!
For the open closed principle how would you avoid rewriting the driver code that instantiates all the classes that follows the open close principle?
It depends on your use-case. You may not need all of them (strategy-like) and if you do you can probably put them in a factory.
very well made video!
Is it just me or I see no major difference between Liskov Principle and Dependency Inversion Principle?
😂😭😁🤝