In the context of the example of the Shape class and its functionality i.e. just to compute area, there is nothing wrong with the Square class extending from the Rectangle class. It does not violate the LSP either, you can actually replace any instance of the Rectangle class with an instance of the Square class. However if you have a Rectangle class with setter methods for both Lenth and Breath, making them mutable independently of each other, then extending the Square class from the Rectangle class would violate the LSP. Because calling setHeight() and setWidth() on an instance of Square class would change the other property, which in purely programming construct might fail a few tests. An important thing not to miss here is the context and functionalities the parent class is providing. They must work even after substituting with an instance of the child/derived class.
If we implement the methods again in the child class when they are already present in the parent class (04:09), then what is the point of inheritance here. Also, the implementation in both parent and child classes is also exactly the same. Aren't we redoing the work and doing code duplication?
probably given a wrong example. but you can image beverage item implementing get price with some custom logic, based on what is the item because bevarages cost more but every other item we can follow standard price
what do we mean by breaking here in the method? even after the implementation of getPrice in BeverageItem(), if I replace menuItem object by beverageItem object, unless we specify the correct instance at creation, we would get the price of beverageItem without discount right? So what are we trying to prevent here? Ensuring that at least we can call the method from both child and parent class or we need to ensure that even if the superClass is replaced by subclass object we get the same response?
Hi Mam, Very informative video. Just wanted to know if the video for open closed principle pending or I might have missed that video. Thank you for producing such a quality content.
Amazing series, Thank You so much ma'am for the awesome LLD series. and is here we missing video for open - close principle? or you'll cover in upcoming videos
The way you explain is really appreciated. If I follow it correctly please clarify once @4:44 A private method in MenuItem class can't be overridden in BreverageItem class.
When you added a new private function to the menuItem. Haven't you break the Open-Close principle of the SOLID? Which states that classes should be open for extension but closed for modification?
Very well explained. One another point I think we can keep in mind is if you are providing any extra functionality (some public methods..) in child class which is not been covered by parent class then its breaking LSP. That's when you will get error when you replace the child instance by parent instance when calling the extra functionality. Correct me if I am wrong.
You said that we define a "private" function getDiscount in MenuItem class and override it in the BeverageItem class, but private methods cannot be overridden.
I am wondering why such less views. Keep on doing the good work. We benefited from these videos. Happy to clear my concepts by watching your videos. Waiting for AOP Spring videos. Or are they already there?
Sorry to say but first example is actually example of open close principle where client code is remain the same due to use of polymorphism (without any instance of condition) LSP mainly deals with 3 concepts of subclass 1. Precondition should not be strengthened- meaning input param validations on overriding methods should be not be more strict than overridden methods 2. Postconditions can’t be weakened- meaning if your parent class method returns a String object in all scenarios then overridden method also should return String and not Null(for exception scenarios) 3. Invariants must be preserved - meaning internal state of object(parent) should be correctly preserved by subclass
You are right with respect to what ocp is but in first example here, Liskov is being violated because as per Liskov, substituting a child instance instead of a parent instance should not require any checks in client code. It can be easy to confuse with ocp because of an overlap. It would be great if you can share the source for the above 3 points. I have taken the first example from the book of four. I can link it.
@@sudocode Great video! What I fail to understand is, if "objects of superclass should be replaceable by objects of subclass" and in this case we replace menuItem() by beverageItem(), we would not get the correct value( as discount would be 0), so essentially what are we trying to prevent by creating a getMethod inside beverageItem()? To get the right response (i.e. with discount) I would have to be mindful of the type of object I create right?
TBH, I don't think the example of square/rectangle was less confusing or even correct. Yes, we have to be mindful but it still fully follows LSP. I can replace all instances of areaCalculator for square with rectangle and the functionality will not be broken in any way. A bad way to satisfy the principle but nonetheless it does satisfy it. The example of getPrice() was fully correct though.
Hi , Thanks for the video. but incase if we have to play more with discount lets say its based on certain % based on some inputs we may violate Single responsibility case. normally such things should be separate class and instance should be in base class. so who wants play with discount they can create object instance for remain it is null.
Thank you for the explanation, it's helpful. I have one question: In java service with persistence layer what normally I have seen: There are entities which shares some common fields such as ID, createTime, UpdateTime etc.. So what people normally do is they create BaseEntity where they will have these three fields and all other fields will be specified in child (or main entity classes). Here I believe Parent class (BaseEntity) and child classes (say UserEntity) are not replaceable when passing to some function. Or is it ? So in this design are we violating Liskov's principle ?
For some situations, you have to think mindfully and hence the flexibility comes in. Think about it, where exactly would you use BaseEntity in your service class? Would you do that ever? No, right? So, you don't have to think of the substitutions ever in case. On the other hand, if you have exposed a Shape class and the children classes like Square, Rectangle or Circle, you may very well use List shapes in your service classes for some generalised answers like getting total areas or the sum of areas, etc.
First of all, thanks for making in detail video. You create very good content to refer. One request, could you please plan to upload video on 'Open Close Principle' soon.
Hi Ma'am, Well explanation!!! Can i extend the functionality of a child class if needed like adding new functions to the child class along with the existing methods of parent class
Yogita, Thanks for the video. I have some questions: 1. While designing Menu class it seems like I have to think of the future cases like discount etc and after designing when a new requirement comes which needs to extend Menu class and add some features then I will have to refactor Menu again. Is it right? 2. Suppose, rectangle has a method getLeftArmLength() (Just say this method returns length of an arm) then Inheriting from rectangle I can use it in square as well. But inheriting from shape I have to implement that method both on rectangle and square. Doesn't it reduces code re-usability?
difficult to understand the content as you are speaking and I have to visualize your entire spoken code in my mind....it would be good if you write and show and speak along writing the code...
LSP cannot be explained simpler than this 😇 How is having "private double getDiscount()" method only in BeverageItem gonna break LSP ? as this is a private method, inheritance/method override is not applicable here , so it doesn't violate LSP.
I think the first example was great. You could have done a better job in explaining the second example. The second example was not that intuitive. If you could have provided the code for second example, that would have helped a lot.. :)
Explanation not sufficient for beginner. especially for example of shape, rectangle and square . I get it. But i hope it could be better if you explain how mock comes to picture
Loved it. I think need on correction here. We can not override the Private method. We can Hide the method using given example. ruclips.net/video/HbGDobtxzWk/видео.html
Thank you for having my back Nitish. I have stepped up to be an engineering manager last quarter. I am trying my best to push content but I don’t want to compromise on quality. This quarter hopefully we finish the series 🙏
What if we define the getPrice() in the MenuItem class only with a parameter named "discount" and we set its default value to 0. int getPrice(int discount = 0) { return this.price - discount * this.price/100} Now when we want to calculate price for BeverageItem we simply use the BeverageItem instance (bev_item) and do this --> bev_item.getPrice(discount = 0) With such implementation can we say that LSP is followed correctly ?
In the context of the example of the Shape class and its functionality i.e. just to compute area, there is nothing wrong with the Square class extending from the Rectangle class. It does not violate the LSP either, you can actually replace any instance of the Rectangle class with an instance of the Square class.
However if you have a Rectangle class with setter methods for both Lenth and Breath, making them mutable independently of each other, then extending the Square class from the Rectangle class would violate the LSP. Because calling setHeight() and setWidth() on an instance of Square class would change the other property, which in purely programming construct might fail a few tests.
An important thing not to miss here is the context and functionalities the parent class is providing. They must work even after substituting with an instance of the child/derived class.
One of the best tutors on youtube. Thanks yogita for the series. :)
You actually told the essence of LSP. Thanks for that.🙂
If we implement the methods again in the child class when they are already present in the parent class (04:09), then what is the point of inheritance here. Also, the implementation in both parent and child classes is also exactly the same. Aren't we redoing the work and doing code duplication?
exactly my point
probably given a wrong example.
but you can image beverage item implementing get price with some custom logic, based on what is the item because bevarages cost more
but every other item we can follow standard price
Thanks you so much Yogitha Madam, this is invaluable, you have explained it with very simple and effective exampes.
Your videos are always crisp and to the point. ❤
amazing.. it will be icing on the cake if you make a video on SOLID with a system design example..like parking lot
Please add the videos frequently .. i am literally waiting for your videos
This is a treasure of knowledge. Thanks a lot for this video.
what do we mean by breaking here in the method? even after the implementation of getPrice in BeverageItem(), if I replace menuItem object by beverageItem object, unless we specify the correct instance at creation, we would get the price of beverageItem without discount right?
So what are we trying to prevent here? Ensuring that at least we can call the method from both child and parent class or we need to ensure that even if the superClass is replaced by subclass object we get the same response?
I'm with you, this is not a violation of the LSP
Hi Mam, Very informative video. Just wanted to know if the video for open closed principle pending or I might have missed that video.
Thank you for producing such a quality content.
Hi Yogita, can you please make a video on the open closed principle "O" of SOLID? Is there a reason for that being left out?
Same question.
Great explanation! Thanks!
Amazing series, Thank You so much ma'am for the awesome LLD series. and is here we missing video for open - close principle? or you'll cover in upcoming videos
The way you explain is really appreciated. If I follow it correctly please clarify once @4:44 A private method in MenuItem class can't be overridden in BreverageItem class.
Second principal video 'O' is not available in the playlist and i can't even find it in your channel
Your api rate limit vedio is very awesome👍
@yogita, you missed to make open-close principle video
best video on Liskov
When you added a new private function to the menuItem. Haven't you break the Open-Close principle of the SOLID? Which states that classes should be open for extension but closed for modification?
Can you please also make a video on Open-Close principle ? It's confuses me the most
Very well explained. One another point I think we can keep in mind is if you are providing any extra functionality (some public methods..) in child class which is not been covered by parent class then its breaking LSP. That's when you will get error when you replace the child instance by parent instance when calling the extra functionality. Correct me if I am wrong.
The theorem says about replacing parent instance by child instance :)
@@sudocode Mam please complete remaining video of solid principles. Your explanation is amazing 👍
Thanks for the amazing content. But I'm confused, have you skipped Open close principle intentionally or I'm missing something?
We lost the video for ocp, only left with audio. Will record again and release.
@@sudocode Thanks for clarifying. Keep up the good work you are doing. Thanks for the content once again.
@@sudocode Can you please upload the video for ocp, its a missing piece in the puzzle and the series, Thanks in advance , eagerly waiting !
You said that we define a "private" function getDiscount in MenuItem class and override it in the BeverageItem class, but private methods cannot be overridden.
LSP is an extension of Open Close Principle. But in above example LSP is violating OCP.
I will make to big company, if not today if not tomorrow but very soooon . BTW Thanks for the help for the course for free .
Well what should I say, i was actually unable to understand this 3rd principle but after watching this video I clearly understand the concept....
On time 4:00 min you said the code is a violation but on 5:53 you are saying the same code as not violation to LS. Little confused around it.
I am wondering why such less views. Keep on doing the good work. We benefited from these videos. Happy to clear my concepts by watching your videos. Waiting for AOP Spring videos. Or are they already there?
can we plz have 2nd principle OCP that is missing
Sorry to say but first example is actually example of open close principle where client code is remain the same due to use of polymorphism (without any instance of condition)
LSP mainly deals with 3 concepts of subclass
1. Precondition should not be strengthened- meaning input param validations on overriding methods should be not be more strict than overridden methods
2. Postconditions can’t be weakened- meaning if your parent class method returns a String object in all scenarios then overridden method also should return String and not Null(for exception scenarios)
3. Invariants must be preserved - meaning internal state of object(parent) should be correctly preserved by subclass
You are right with respect to what ocp is but in first example here, Liskov is being violated because as per Liskov, substituting a child instance instead of a parent instance should not require any checks in client code. It can be easy to confuse with ocp because of an overlap. It would be great if you can share the source for the above 3 points. I have taken the first example from the book of four. I can link it.
@@sudocode let me check gof for first example.
I used wiki for those 3 points en.m.wikipedia.org/wiki/Liskov_substitution_principle
As far as I have checked, gof book does not explain LSP, It’s only for design patterns.
@@sudocode Great video! What I fail to understand is, if "objects of superclass should be replaceable by objects of subclass" and in this case we replace menuItem() by beverageItem(), we would not get the correct value( as discount would be 0), so essentially what are we trying to prevent by creating a getMethod inside beverageItem()? To get the right response (i.e. with discount) I would have to be mindful of the type of object I create right?
Thanks for the amazing videos, which course are you recommending on educative ? Link seems to be showing something else.
Is it just me who can't find the Open-Closed Principle video in the SOLID principles list?
there is none
TBH, I don't think the example of square/rectangle was less confusing or even correct. Yes, we have to be mindful but it still fully follows LSP.
I can replace all instances of areaCalculator for square with rectangle and the functionality will not be broken in any way. A bad way to satisfy the principle but nonetheless it does satisfy it.
The example of getPrice() was fully correct though.
Can we override private method getDiscount() from parent class to child class BeverageItem? Needs little bit clarity on this.
Yes you can
@@sudocode I think private method can't be overridden. Then how this works here. Please help me out.
why are getDiscount functions private
Hi , Thanks for the video. but incase if we have to play more with discount lets say its based on certain % based on some inputs we may violate Single responsibility case. normally such things should be separate class and instance should be in base class. so who wants play with discount they can create object instance for remain it is null.
Thanks a lot!
Thank you for the explanation, it's helpful. I have one question: In java service with persistence layer what normally I have seen:
There are entities which shares some common fields such as ID, createTime, UpdateTime etc.. So what people normally do is they create BaseEntity where they will have these three fields and all other fields will be specified in child (or main entity classes). Here I believe Parent class (BaseEntity) and child classes (say UserEntity) are not replaceable when passing to some function. Or is it ? So in this design are we violating Liskov's principle ?
For some situations, you have to think mindfully and hence the flexibility comes in. Think about it, where exactly would you use BaseEntity in your service class? Would you do that ever? No, right? So, you don't have to think of the substitutions ever in case.
On the other hand, if you have exposed a Shape class and the children classes like Square, Rectangle or Circle, you may very well use List shapes in your service classes for some generalised answers like getting total areas or the sum of areas, etc.
First of all, thanks for making in detail video. You create very good content to refer. One request, could you please plan to upload video on 'Open Close Principle' soon.
Sure. It will be uploaded soon.
Real life code example at 2:58
Hi Ma'am,
Well explanation!!!
Can i extend the functionality of a child class if needed like adding new functions to the child class along with the existing methods of parent class
Yes, you can
Yogita, Thanks for the video. I have some questions:
1. While designing Menu class it seems like I have to think of the future cases like discount etc and after designing when a new requirement comes which needs to extend Menu class and add some features then I will have to refactor Menu again. Is it right?
2. Suppose, rectangle has a method getLeftArmLength() (Just say this method returns length of an arm) then Inheriting from rectangle I can use it in square as well. But inheriting from shape I have to implement that method both on rectangle and square. Doesn't it reduces code re-usability?
I think these principle are very subjective, and one can argue over how his design is better, over others in many ways.
Hi Ma'am,
Can you please add Open Closed Principle Video too?
Can you please include the open close principle, its been long now...
Amazing!
difficult to understand the content as you are speaking and I have to visualize your entire spoken code in my mind....it would be good if you write and show and speak along writing the code...
True..!!
LSP cannot be explained simpler than this 😇
How is having "private double getDiscount()" method only in BeverageItem gonna break LSP ? as this is a private method, inheritance/method override is not applicable here , so it doesn't violate LSP.
It won’t. Let me know where it is mentioned in time stamp. Might be an error in speaking or slides.
@@sudocode ruclips.net/video/HbGDobtxzWk/видео.html
@@sudocode 4:48
Thanks mam
Very well explained thanks!
It means subclass should not have any specific methods which are not there in super class and subclass can have only private methods
This is my understanding some one confirm please @sudoCode
how many of you are waiting for OCP video ? :P
For more clarity, follow : www.oodesign.com/liskov-s-substitution-principle
I think the first example was great. You could have done a better job in explaining the second example. The second example was not that intuitive. If you could have provided the code for second example, that would have helped a lot.. :)
Agreed.
Explanation not sufficient for beginner.
especially for example of shape, rectangle and square .
I get it. But i hope it could be better if you explain how mock comes to picture
1. The video was crisp and upto the point with awesome explanation.
2. #crush updated😆
Loved it.
I think need on correction here. We can not override the Private method. We can Hide the method using given example.
ruclips.net/video/HbGDobtxzWk/видео.html
series agle saal khatam hoga lag rha h.
Dude she is a software engineer as well she has to take care of her job also . Please be grateful for such wonderful content. Thanks
Thank you for having my back Nitish. I have stepped up to be an engineering manager last quarter. I am trying my best to push content but I don’t want to compromise on quality. This quarter hopefully we finish the series 🙏
Sorry but Not so clear...
What if we define the getPrice() in the MenuItem class only with a parameter named "discount" and we set its default value to 0.
int getPrice(int discount = 0)
{ return this.price - discount * this.price/100}
Now when we want to calculate price for BeverageItem we simply use the BeverageItem instance (bev_item) and do this -->
bev_item.getPrice(discount = 0)
With such implementation can we say that LSP is followed correctly ?
The idea is that caller should not know about the discount.
Amazing!