An excellent explanation of Liskov's Substitution principle. I work primarily with python and javascript, and your explanation really illustrates well why typescript and type hinting in python are necessary to avoid errors. Thank you very much.
One suggestion - hasEngine could have values - true and false. So instead of returning null, we could have returned false, and it would not break. For this example, we could have taken something like engineType instead of engine. In that case, cycle will have to return null. PS - I am new to these topics. Please correct me if i am wrong 🙂
:) yes, i think you got the point. Enginetype can be better functionality. but hasEngine is returning Boolean class type, so null is one of the valid return type here.
I was thinking the same thing. But then a car who should have an engine could have no (hasEngine returns false) engine. So it perfectly illustrates why a bicycle returns a null and shouldn't have the hasEngine method in the first place.
@anuragupta I have same question in my mind also. Yes if we use engineType functionality it will be better instead of hasEngine. Thank you shreyansh sir.
This brings the point when to ditch Inheritance over Composition. Like how Abstraction/Inheritance brings coupling along with itself. Though, both Inheritance and Composition will have it's own pros/cons. Amazing playlist!
very nice explanation! can you also add similar video explanation for all the other principles? This is a rock solid video, I don't think I will forget this easily.
Hi Shrayansh, 1) The vehicle class, does it follow a single responsibility principle. 2) What if I return false instead of return null for the bicycle class, does it follow LSP
I think there is a slight conceptual mistake in the start of the video. In the video, you mentioned that for a parent p, and child classes c1, c2, and c3, LSP says that parent *p = new c1should not break the behavior when c1 is replaced by c2, c1 is replaced by c3. However, my understanding is that for the same scenario, in a code, if you use c1_object.setSomething() or c2_object.setSomething() and if you have a parent object, the code should retain its behavior if you change c1_object with p1_object. Please correct my understanding if it's wrong.
The solution proposed seems to be similar to Interface Segregation principle with the only difference being we use classes here instead of interfaces for segregation. Thanks for the explanation.
One more thing that comes into mind is separation of behaviours. We can set up behaviors as interfaces and select class can implement that interface while the rest need not have to. (Learnt this through an example in Head First Design Patterns) Shreyansh Jain, correct me if I am wrong. With this, we don't have to create more classes.
Hi Gurupreet, i want to show the example. If Return type is Boolean, then returning null is also a valid. What i wanted to showcase that these kind of scenarios Liskov principles try to avoid. :)
In this case, I feel a better example would be to replace hasEngine with engineType in Vehicle class. For the case of bicycle, It would be logical to return null. So it would be better to understand why it is wrong to use that way.
@@gurupreetsingh8347Just because implementation fits for that method doesn’t mean, we can have method. In Bicycle has per its behaviour there is not question of having engine, also if it is electricVehicle suppose, there you can return false.
i think i should name method little different which will make more sense. but in this example, return type is Boolean, so its a valid that NULL can be returned from this method, if it is returned, then it might break the existing code. That breaks Liskov principle
As hasEngine method return either true if engine is available and false if not available then in case of BiCycle you are returning null, shouldn't it be returning "false"?
Will the problem arise if we have primitive boolean instead of Wrapper object Boolean and return false ? If we return false then it will follow the Liskov's substitution principle right ?
I could, but since the return type of method is 'Boolean' and null can also be returned, so that's a possible usecase. But yes I could have used some better method name.
Can we not return false for hasEngine in Bicycle? May be different example can be used getEngine() to show the problem. Nice explanation btw. I searched the internet most of them gives complex example without clearing much. PS: Instead of EngineVehicle we can rename MotorizedVehicle. just a thought.
I think, Returning null is typically used when dealing with reference types, where a variable can hold a reference to an object or have no reference (null). However, for Boolean values, the options are limited to true or false to indicate the presence or absence of a certain condition. Please correct me!
One question i.e I think we used multi-level inheritance to make sure that we follow strategy design pattern practises? please correct me if I am wrong.
Good explanation but probably the example could have been a little better for instance Bicycle's hasEngine method could simply return false in this case no need to return null. So this use-case of having Bicycle extending vehicle is not basically causing any trouble :)
Similar, but intention is different, it tries to solve problem from code which uses interface. Interface segregation says we should not force child class to implement method which it font require. But Liskov days, if we swap with other child class, code should not break
While they address different concerns, Interface Segregation Principle (I) can be considered a solution to avoid violating Liskov Substitution Principle (L) by designing more cohesive interfaces.
Agree with you. Generally the example should be in such a way that substitution doesn't change/break the existing implementation. Not introduce exception voluntarily.
@@ConceptandCoding in any of the programming language Bool is not have null value mate.. Its either True/ False otherwise the whole meaning of Bool is wasted
@@Jock3R87 welcome to Java world buddy, it's a wrapper object and null is valid value for it. Yes generally it make sense to return only true false but since we define the return type as Boolean object not the primitive one boolean. , Null can be passed. Hope this clarifies
TH-cam and people like you have made life easier, thankuu.
An excellent explanation of Liskov's Substitution principle. I work primarily with python and javascript, and your explanation really illustrates well why typescript and type hinting in python are necessary to avoid errors.
Thank you very much.
Thanks
One suggestion - hasEngine could have values - true and false. So instead of returning null, we could have returned false, and it would not break.
For this example, we could have taken something like engineType instead of engine. In that case, cycle will have to return null.
PS - I am new to these topics. Please correct me if i am wrong 🙂
:) yes, i think you got the point.
Enginetype can be better functionality.
but hasEngine is returning Boolean class type, so null is one of the valid return type here.
I was thinking the same thing. But then a car who should have an engine could have no (hasEngine returns false) engine. So it perfectly illustrates why a bicycle returns a null and shouldn't have the hasEngine method in the first place.
@anuragupta I have same question in my mind also.
Yes if we use engineType functionality it will be better instead of hasEngine.
Thank you shreyansh sir.
This brings the point when to ditch Inheritance over Composition. Like how Abstraction/Inheritance brings coupling along with itself. Though, both Inheritance and Composition will have it's own pros/cons. Amazing playlist!
This is the perfect Explanation of this principle, i watched this principle in paid courses, but this is the perfect explanation
Best example of Liskov's substitution principle
Thank you
Awesome work ! I have been working for a while but you cleared concepts with examples!
Thanks
No one explained like you this solid concept..thanks
very nice explanation!
can you also add similar video explanation for all the other principles? This is a rock solid video, I don't think I will forget this easily.
Pls check the first video of this playlist
Beautifully explained !!! keep up the good work !!!
Hi Shrayansh,
1) The vehicle class, does it follow a single responsibility principle.
2) What if I return false instead of return null for the bicycle class, does it follow LSP
I assume that the method hasEngine() should be replaced with the method startEngine(). Then this tutorial will make sense.
Thanks , can I know whether it follows single responsibility priciple
I think there is a slight conceptual mistake in the start of the video.
In the video, you mentioned that for a parent p, and child classes c1, c2, and c3, LSP says that parent *p = new c1should not break the behavior when c1 is replaced by c2, c1 is replaced by c3.
However, my understanding is that for the same scenario, in a code, if you use c1_object.setSomething() or c2_object.setSomething() and if you have a parent object, the code should retain its behavior if you change c1_object with p1_object.
Please correct my understanding if it's wrong.
Bro by the way, Would like to study together LLD, HLD and DSA for interview? I'm also preparing for the google.
Sure man@@patel5532
It should be reverse......the code should retain its behaviour if you change p1_object with c1_object
So beautifully explained!
The solution proposed seems to be similar to Interface Segregation principle with the only difference being we use classes here instead of interfaces for segregation. Thanks for the explanation.
One more thing that comes into mind is separation of behaviours. We can set up behaviors as interfaces and select class can implement that interface while the rest need not have to. (Learnt this through an example in Head First Design Patterns) Shreyansh Jain, correct me if I am wrong. With this, we don't have to create more classes.
Right that's interface segregation
In side bicycle u could return false instead of null ... Why returning null .. returning false can solve the problem..
Hi Gurupreet, i want to show the example.
If Return type is Boolean, then returning null is also a valid.
What i wanted to showcase that these kind of scenarios Liskov principles try to avoid.
:)
@@ConceptandCoding ok thanks
In this case, I feel a better example would be to replace hasEngine with engineType in Vehicle class. For the case of bicycle, It would be logical to return null. So it would be better to understand why it is wrong to use that way.
@@gurupreetsingh8347Just because implementation fits for that method doesn’t mean, we can have method. In Bicycle has per its behaviour there is not question of having engine, also if it is electricVehicle suppose, there you can return false.
Instead you could have turnOnEngine like in SOLID video , Cycle cannot turn on engine.
3:41 but why we are returning null we can return the false as well right.
Boolean is a wrapper class and null is also a valid value.
So for example purpose i sent null.
Amazing... thank you for such clear explanation!
Thanks
Great explanation man!!
Very Nice Bhaiya Got it properly!!!
Thank you
Very well explained thanks
Amazing solution!
Thank you
Simple and clear Explanation
Very well explained...awsome!!!
Superb explanation.👏👏
Good example to understand. thanks for your efforts
since bicycle has not engine what if you return false since its return type is boolean. will it meet Liskov principle?
i think i should name method little different which will make more sense.
but in this example, return type is Boolean, so its a valid that NULL can be returned from this method, if it is returned, then it might break the existing code. That breaks Liskov principle
great explanation.......
Nicely explained with help of example 😊
Thank you
Can we get the slides that you are sharing in your videos?
As hasEngine method return either true if engine is available and false if not available then in case of BiCycle you are returning null, shouldn't it be returning "false"?
Hi , Even after all of the changes , in the 2nd case where Bicycle cant access hasEngine(),It still throws error right,How could we prevent this ?
same question
Why bikecycle returned NULL instead of false for hasEngines()?
I wanted to give an example, since method return type is Boolean (object), Null is a valid return value.
Will the problem arise if we have primitive boolean instead of Wrapper object Boolean and return false ?
If we return false then it will follow the Liskov's substitution principle right ?
very good. thank you.👏👏👏👏
Hi In your BiCycle method it is of type boolean and you are returning null ?
thats a great explanation
Nice information brother 😊 keep sharing
Thank you
Very well explained
Thanks
Thank you so much for the wonderful explanations
Thanks
You could have return false in place of null in case of Bicycle's hasEngine() method?
I could, but since the return type of method is 'Boolean' and null can also be returned, so that's a possible usecase.
But yes I could have used some better method name.
Can we not return false for hasEngine in Bicycle? May be different example can be used getEngine() to show the problem. Nice explanation btw. I searched the internet most of them gives complex example without clearing much. PS: Instead of EngineVehicle we can rename MotorizedVehicle. just a thought.
yes, thats the example i wanted to showcase, but since its Boolean, null is the valid return value
I think, Returning null is typically used when dealing with reference types, where a variable can hold a reference to an object or have no reference (null). However, for Boolean values, the options are limited to true or false to indicate the presence or absence of a certain condition. Please correct me!
I dont understand why you need to return null from hasEngine method in the Bicycle class. Shouldn't it just return false?
return type is Boolean it can return null,
but i agree method name i can take something else to explain it better
One question i.e I think we used multi-level inheritance to make sure that we follow strategy design pattern practises? please correct me if I am wrong.
sorry i could not understand the relation between multi-level and strategy pattern, could you pls elaborate.
@@ConceptandCoding sorry i think i got it wrong, thanks for addressing
I have joined via membership but still can’t get the access to the few videos. Somebody help me
Could you pls check if you have the right membership level
Fantastic 😍!
Thanks
Thanks for this video!
Thanks
great explanation
very nice explanation
Thanks
Best Explanation
thanks
why to make different classes implementing interfaces. Why cant we have interface extending another inteface?
How do we solve above problem?
Last Mai toh wapas conflict ho Gaya !
Compiler error hai , solve kaise hoga wo ?
Thanks for video aag laga diya hai 🔥
same doubt
Shrayansh Sir, please share the slides link.
Very good explanation indeed
thank you
Very informative video!
Good explanation but probably the example could have been a little better for instance Bicycle's hasEngine method could simply return false in this case no need to return null. So this use-case of having Bicycle extending vehicle is not basically causing any trouble :)
Return type is Boolean, so null is a valid return type.
Yes i think much better example can be used
Why a boolean method returning NULL, Bicycle could have returned False instead
I wanted to show an example.
Since it's a wrapper object, Null is a valid return type
@@ConceptandCoding understood
Great teaching. Do you have notes also ? that u can share
can we make vehcile as interface ?
So, solution for LSP is to use ISP? In other words, use a different principal ?
Where can i get lld notes
can u give slides you are using in videos for reference
sir is this for freshers or for sed1, or sde 2. now i am working on my dsa.
LLD is asked for freshers too buddy
Isn't this looking like similar to I in Solid - interface segregation
You are segregating the interfaces based on their functionalities
isn't also interface segregation principle?
Similar, but intention is different, it tries to solve problem from code which uses interface.
Interface segregation says we should not force child class to implement method which it font require.
But Liskov days, if we swap with other child class, code should not break
What is the difference between L and I then.
Does this mean I is the solution of L??
While they address different concerns, Interface Segregation Principle (I) can be considered a solution to avoid violating Liskov Substitution Principle (L) by designing more cohesive interfaces.
@@ConceptandCoding Got it, Thanks😄
why the bicycle is not returning false instead of null...this will not break the code.
return type of the method is Boolean, so returning Null is a valid return type.i think method can be improved a bit
amazing
good explanation
bhai❣
Did you provide code and this file?
sir if you could share a git link. I am trying these in python
Sure will add
This is not really a satisfactory example.
Agree with you. Generally the example should be in such a way that substitution doesn't change/break the existing implementation. Not introduce exception voluntarily.
bro can I get the pdf of these notes?
If possible can u please provide notes ?
Thank you❤
Thanks
Could you please provide the codes or notes pdf
Sure will add soon
Combine it in one shot sir
In bicycle class you are returning nil ideally it should return false.. i guess this is not the correct example
Return type is Boolean, null is a valid return value.
@@ConceptandCoding in any of the programming language Bool is not have null value mate.. Its either True/ False otherwise the whole meaning of Bool is wasted
@@Jock3R87 welcome to Java world buddy, it's a wrapper object and null is valid value for it.
Yes generally it make sense to return only true false but since we define the return type as Boolean object not the primitive one boolean. , Null can be passed. Hope this clarifies
Your slide
Hi Shreyansh, So the solution is strategy design pattern , am i right ?
:) no Abhishek, i would say, interface segregation generally solves this
Will it work if I do -> System.out.println(engineVehicle.getNumberOfWheels());