Your videos are some of the best OOP videos I found on RUclips. I binge watched most of the videos, and they are one of the clearest OOP tutorials I have seen.
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!
The solution in Liskov substitution principle with VideoManager breaks the Single Responsibility Principle, now one class is responsible for two totally different behaviors.
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.
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?
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
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
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 :)
7:20 wouldn't just be better if we could just create a base class that doesn't have playRandomAd methods and have both video and videoPremium class inherited it and implements playRandomAd inside video instead. Does that make sense? So we have the option to either override methods from base or not and also helps us reducing number of lines code.
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.
Your videos are some of the best OOP videos I found on RUclips. I binge watched most of the videos, and they are one of the clearest OOP tutorials I have seen.
Glad to read it! Thank you :)
Your videos clear all my doubts. Thanks
Perfectly explained in 11 minutes! Thanks!
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?
Best video I have ever seen on SOLID design principles!
This video is amazing. Your channel is underrated, you're great at teaching
Thank you so much :) I really appreciate it!
best and straightforward video I have watched on this topic. Thanks you
The solution in Liskov substitution principle with VideoManager breaks the Single Responsibility Principle, now one class is responsible for two totally different behaviors.
The most underrated channel ever!
Underrated great explanation
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
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.
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!
perfectly explained
Very well explained..❤
Excellent video
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
Really excellent! Thank you!
Thanks for the video. Came up with a question. Is the VideoManager class in Liskov's Substitution Principle not violating SRP?
Underrated channel . Like and shared. Thanks a lot for the efforts🙏
Thanks for the support :)
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
wow this video was beautifully made.
Super incredible, I enjoyed every single second
Glad you enjoyed it! Happy to help :)
Super helpful
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! :)
7:20 wouldn't just be better if we could just create a base class that doesn't have playRandomAd methods and have both video and videoPremium class inherited it and implements playRandomAd inside video instead. Does that make sense? So we have the option to either override methods from base or not and also helps us reducing number of lines code.
Absoloutly superb explanation! Thanx!!!
Glad it was helpful! You're welcome :)
good refresher
Great explanation!
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...
Thank you❤
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
Thanks sir, it's very clear
Great video with great examples and explanation!
Thank you :) Glad you liked it!
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!
very well made video!
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.
Is it just me or I see no major difference between Liskov Principle and Dependency Inversion Principle?
😂😭😁🤝