Your videos are some of the best OOP videos I found on TH-cam. 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!
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
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.
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 :)
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?
Im confused about the open closed principle. In the example, it says we can extend the class by adding new earning calculator classes. but wouldnt we still need to add another enum to the original video class?
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.
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!
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.
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 TH-cam. 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 :)
This video is amazing. Your channel is underrated, you're great at teaching
Thank you so much :) I really appreciate it!
Best video I have ever seen on SOLID design principles!
Perfectly explained in 11 minutes! Thanks!
Your videos clear all my doubts. Thanks
best and straightforward video I have watched on this topic. Thanks you
The most underrated channel ever!
Underrated great explanation
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?
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
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 channel . Like and shared. Thanks a lot for the efforts🙏
Thanks for the support :)
Very well explained..❤
Super incredible, I enjoyed every single second
Glad you enjoyed it! Happy to help :)
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.
Really excellent! Thank you!
wow this video was beautifully made.
Excellent video
The solution in Liskov substitution principle with VideoManager breaks the Single Responsibility Principle, now one class is responsible for two totally different behaviors.
Absoloutly superb explanation! Thanx!!!
Glad it was helpful! You're welcome :)
perfectly explained
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! :)
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!
Great video with great examples and explanation!
Thank you :) Glad you liked it!
good refresher
Im confused about the open closed principle. In the example, it says we can extend the class by adding new earning calculator classes. but wouldnt we still need to add another enum to the original video class?
Thank you❤
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...
Great explanation!
Super helpful
Thanks for the video. Came up with a question. Is the VideoManager class in Liskov's Substitution Principle not violating SRP?
Thanks sir, it's very clear
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.
i thought so too
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!
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 made video!
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
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
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?
😂😭😁🤝