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?
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...
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
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?
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.
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.
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?
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.
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
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?
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.
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?
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?
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.
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.
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.
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.. :)
Loved it. I think need on correction here. We can not override the Private method. We can Hide the method using given example. ua-cam.com/video/HbGDobtxzWk/v-deo.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.🙂
amazing.. it will be icing on the cake if you make a video on SOLID with a system design example..like parking lot
Your videos are always crisp and to the point. ❤
Please add the videos frequently .. i am literally waiting for your videos
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
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..!!
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.
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
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
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.
Can you please also make a video on Open-Close principle ? It's confuses me the most
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 .
Second principal video 'O' is not available in the playlist and i can't even find it in your channel
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 👍
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.
This is a treasure of knowledge. Thanks a lot for this video.
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?
Your api rate limit vedio is very awesome👍
@yogita, you missed to make open-close principle video
Well what should I say, i was actually unable to understand this 3rd principle but after watching this video I clearly understand the concept....
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 !
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.
LSP is an extension of Open Close Principle. But in above example LSP is violating OCP.
best video on Liskov
Great explanation! Thanks!
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.
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
Is it just me who can't find the Open-Closed Principle video in the SOLID principles list?
there is none
Thanks for the amazing videos, which course are you recommending on educative ? Link seems to be showing something else.
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?
Hi Ma'am,
Can you please add Open Closed Principle Video too?
can we plz have 2nd principle OCP that is missing
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.
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.
Can you please include the open close principle, its been long now...
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?
why are getDiscount functions private
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.
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.
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 ua-cam.com/video/HbGDobtxzWk/v-deo.html
@@sudocode 4:48
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.
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
Amazing!
Thanks a lot!
Very well explained thanks!
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.
Thanks mam
For more clarity, follow : www.oodesign.com/liskov-s-substitution-principle
how many of you are waiting for OCP video ? :P
Real life code example at 2:58
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.
ua-cam.com/video/HbGDobtxzWk/v-deo.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!