I am so excited for the part 2. Especially for the past several years I've been avoiding variance, covariance etc and could really use his intuitive explanation.
Hey Christopher, Hope you're very fine! I got shocked why did you stop this serious.. where are other parts..?? You're awesome teacher and really you've the skill of explain things in a very clear and easy way.. please don't stop producing these kinds of videos. waiting for other parts .. really in a big need to them .. really appreciate your efforts .. Keep it up!
So the quote states, that we shouldn't use inheritance :D Or there is an error. :D. LSP is says that we should adhere to method argument and return types, when using implementation or when extending abstract declarations or overrides. Usually when you do not do that, but implement Interface with type declarations you get Type Error. 🙂 And we have to understand that type declaration can be abstract or interface, so child classes can be a fit for as an argument or return type.
I have been watching online training videos for more than 15 years and the you can spot a great teacher when they have as much energy and enthusiasm as you do. Fantastic video
Break Liskov is too easy, that's another reason because we should not use inheritance just for "reuse" code porpuse. Well if you know what are u doing, please feel free to use inheritance. But even Efective Java encurage developer to prefer composition instead of inheritance. My point is when we use inheritance IMHO we are so naive and we think that we can handle it, but finally we get a dog that acts like a airplane (LOL) and we have broken Liskov.
Thank you Roberto. That's quick and easy to understand. If inheriting from dog you end up with an airplane = breaking of the Liskov's substitution principle. Quick and easy to remember. LOL. From now on I'm going to use your explanation.
Thank you. You have really helped me understand Design Patterns and now SOLID. You are not assuming we know what you're talking about and that really helps get your knowledge across.
Let's say you need to do a task in your domain, and you have to implement a method for it. First you write the test that this method needs to pass (using JUnit for example) and then you write the implementation of the method. Hope this helps. :)
If "someThing" can be said about x, then the same thing should be true, when said about y. Where y is a more specific object than x. Example: - "Cake is sweet", "Pastry is sweet?" true. Ok LSP holds. - "In a Rectangle, sides don't have to be the same". "In a Square, sides don't have to be the same?", false. LSP broke.
The name of that symbol is "theta" - it is one of the Greek letters.. ---------------------------------------------------------------------------------------------------------- Example: Where theta is a property, let theta = liquid (the chosen property for theta to represent is "liquid") Let X (sub1) = water and let X (sub2) = orange juice Then theta(X sub1) = the liquid which is water And theta (X sub2) = the liquid which is orange juice if you have a PARENT class theta(X sub0) where X sub0 = what makes liquid liquid (eg: viscosity, malleability, flow, boiling point) then CHILD class theta(X sub1) and CHILD class theta(X sub2) should each also have viscosity, malleability, flow, boiling point and they be defined identically to theta(X sub0). Any ways that theta(X sub1) and theta(X sub2) differ from one another can not alter the base behavior that defines liquid (viscosity, malleability, flow, boiling point). They can add to that base behavior in a way that makes each child more specific than the parent it inherits from (eg: color, smell, taste) but the base part of that child class that is inherited can not be altered by those extensions. In this way either of theta(X sub1) or theta(X sub2) can be substituted for the parent class theta(X sub0) in any place in the program without failing. I think
Our brains don't have any problem with this principle when we deal with interfaces. Implementing classes MUST adhere with the behaviors of the interface they implement. For example, a class that directly or indirectly implements that interface must have those implementing methods. For example, any class that implements Sortable interface, must be sortable by definition along with any its subclasses. HOW they sort can be different, but they have to be sortable. You can cheat by having an empty method in any class. HOWEVER, no matter which type or subtype of Sortable you put in the code, you should be able to call the "sort" method. This is why we "code to interfaces" by doing this: class T implements Sortable {} class S extends T {} Sortable x = new T(); Sortable y = new S(); x.sort(); // you could replace anywhere in the code you see that with => y.sort(); y. sort(); // you could replace anywhere in the code you see that with => x.sort(); This LSP in a nutshell!
One thing I never understood about Liskov Substitution Principle is why it exists? I thought a core part of Object Oriented programming is that if you have a reference to a base class, it can refer to an instance of the base class or any derived class, since all of the derived classes "IS-A" base class. Or is Liskov the person who came up with that principle in Object Oriented programming, and that's why it is named after her? Otherwise, why give a name to something that was already a part of Object Oriented programming to begin with? It would be like someone deciding to name addition the "Bubba Joe adding principle", when addition already existed before Bubba Joe came along to give addition his name.
Generally, I really like your explanations. They're very clear and down to earth. But I think this time, you might have over-explained it a tad. I mean, I got it the first time. You say there is more depth to this principle, but if you're not going to delve into that in this video, then I don't see the point in going over the same idea again and again.
Hi Chris, really nice explanation, but you know best part @ 5:36 which my daughter of 3.5 years Liked a Lot, She didn't understand the principle but she likes ur expression a lot ...!!!, Thanks
2020 year, after a lot of videos listening blah blah and blah about Liskov's Substitution, finally understand the Liskov Substitution Principle then I Think this video was awesome need the next one, it's pretty weird that UA-cam is not showing part two on following video, go to authors channel, looking for the part two that never comes.
I just recently learned from one of your videos that the snail would speak, but it would have a NullSpeaking behavior that's returned when you run Speak() on the snail.
I think for the programming side (Java), that means you should make parent as an abstract class (not an interface), then all child like a snake have to inheritance the speak() function, LSPrinciple breaks when the programmer has no idea what to put inside snake's speak() function
by using the abstract class, we can differentiate between Liskov Substitution Principle (logically child can't speak()), and Interface Segregation Principle(child avoid speak())
This is one of the best explanations for this principle that I have been able to find out there. For many of them I would walk away feeling like I understood everything that was being said, but not like a I learned something that I could apply, let alone ideas on how to apply it. I would love for this series to be completed if you have the chance or for you to address the topic as part of another series.
Christopher Okhravi I explained LSP to my friends before exam and they were like “oh that’s it 😮 it’s so easy” and I was like “yeah can you imagine “ and then gave them the link to your UA-cam channel 😁 BTW DIP came in the exam not LSP 😂 except that scenario question with classes and DIP example I think I did well
Hello Christoph, You are awesome. I think I have watched almost all of your sessions on design patterns. This one is also amazing and simplified, but I didn't find the part 2 in this playlist. Could you please help with quick link?
This guy is fucking amazing!!!! I loved the video and this was the principle I didn't get a all..but watching his video I've understood fully! Love it! Subscribed!!!
I think the only way to violate LSP is using "override" keyword for a method. Therefore if I did not use "override" I'm safe. Do you think it is correct?
Good point. Very interesting. I’m not sure actually. I’m suspecting there’s some further complications around generics (i.e. parametric polymorphism, think T in C#) but I need to learn more before I can have an opinion about this :/ Sorry! But thank you very much for watching the video and dropping a comment!
Just discovered your channel... And my my, What a fine job you have done explaining these concepts. I am from a non-Computer Science Background and even I was able to understand the logic in one go !! Seems like it's been more than an year that you did the 1st episode... Not sure why you dropped the Series... but like me many would love to see the 2nd and subsequent episodes in this series. 😇
I would be careful referring to "has a" as always obeying Liskov's Substitution Principle. If the property of "having a" speak strategy in the animal class is provable then a snail sub-type of animal must also be able to prove that property. So although a snail inheriting from the animal class would not be forced to have a speak strategy it would be incorrect to say it obeys Liskov's Substitution Principle. Please let me know if I'm on the right track, or if you think there is more to this idea. Thank You.
And also question - "Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.)" so if we have class Animal and we have Cat which extends animal. And animal has method speak() which is empty and Cat has method speak() which shows 'miaw' in the screen. But we are altering the property (as I see wikipedia also calls methods as properties) of Animal and break corretness of the program. Lets say correct program was that speak() does not show anything to screen. And when we replaced Animal with Cat - program works incorrectly - shows 'miaw'. So then qestion is - how do we solve this problem that we want cat to say 'miaw' with the speak() method, because it makes sense that speak() method shows 'miaw' but at the same time not break this principle? Or we should not overwrite the methods? THen again - why is this feature in the language?
Thank you for the explanation, Christopher. But, what I don't understand is, this principle is always true in Object-Oriented Programming where a type can be always substitutable by its subtype. Can you, please, provide some examples where this principle is violated. Thx again!!
12:02 - if S inherits from T, how it can not have T methods? It is not possible, at least in PHP. Also I do not understand why you call methods as properties? For me property sounds like class variable. This was confusing. Or maybe this principle means that you cannot have empty methods. Like if there is parent class called Animal and has method speak. And we create Snail which extends Animal, and automatically snail has method speak() but we make it empty, or it is empty in Animal class - then maybe this is bad?
Also question - if we want Snail to not have method speak, but snail is still animal, then maybe we just remove speak method from the Animal class. And maybe create some class SpeakingAnimal which has speak mehtod() which extends Animal. And since Animal will not have speak() method, we can make Snail extend Animal.
When I study I vocalize my ideas similar to how Christopher conducts his presentations. I love the demystification of concepts in order to allow more people to get the job done, and enjoy engineering, no reason to be selfish or arrogant, these youtubers are fighting the good fight I think.
So basically it's, "whatever the parent can do, the descendants should be able to do that [and more]"?
Omg, thanks a lot!
it's, "whatever the parent can do, the descendants should at least be able to do that"
@@lordmorgoth7 great words
@@lordmorgoth7 golden words
Yes but the big caveat is just because the child must do what the parent is able to do does not mean the child has to do it in the same fashion
unique perspective and wonderful deconstruction, thanks for sharing :)
it's 2020, still waiting for part 2...
I am so excited for the part 2. Especially for the past several years I've been avoiding variance, covariance etc and could really use his intuitive explanation.
Yup, we're all waiting for the rest.
Still waiting
Is part 2 ever coming? We are all looking forward to it!
It's 2022
Hey Christopher, Hope you're very fine!
I got shocked why did you stop this serious.. where are other parts..??
You're awesome teacher and really you've the skill of explain things in a very clear and easy way..
please don't stop producing these kinds of videos.
waiting for other parts .. really in a big need to them .. really appreciate your efforts .. Keep it up!
part 2 ?
+1
+1
+1
+1
+1
Chris
Yeah, the same here I like him.
2018 almost finished.. still no part 2? you can't do that to us mate :-)... Imagine Game of Thrones not releasing season 8
now after watching season 8, I wish they didn't released it. lol
we would have lived without season 8.
I fully understood LSP when you said on 10:57 "they're trying to show us when we should not use Inheritance and when we shouldn't"
exactly!
So the quote states, that we shouldn't use inheritance :D Or there is an error. :D. LSP is says that we should adhere to method argument and return types, when using implementation or when extending abstract declarations or overrides. Usually when you do not do that, but implement Interface with type declarations you get Type Error. 🙂
And we have to understand that type declaration can be abstract or interface, so child classes can be a fit for as an argument or return type.
I imagine with the actual viral context you may have spare time to continue this series ! The crowd ask for it!
I have been watching online training videos for more than 15 years and the you can spot a great teacher when they have as much energy and enthusiasm as you do. Fantastic video
Break Liskov is too easy, that's another reason because we should not use inheritance just for "reuse" code porpuse. Well if you know what are u doing, please feel free to use inheritance. But even Efective Java encurage developer to prefer composition instead of inheritance. My point is when we use inheritance IMHO we are so naive and we think that we can handle it, but finally we get a dog that acts like a airplane (LOL) and we have broken Liskov.
Thank you Roberto. That's quick and easy to understand.
If inheriting from dog you end up with an airplane = breaking of the Liskov's substitution principle.
Quick and easy to remember. LOL. From now on I'm going to use your explanation.
Bro you are doing a really good job. I really love the way you explain things.. more power to you.
part 2 to save my life
Thank you. You have really helped me understand Design Patterns and now SOLID.
You are not assuming we know what you're talking about and that really helps get your knowledge across.
Thanks! Your comment is super helpful :) Much appreciated :) Thanks for watching and for the feedback :)
I swear, you should be the Dean of my University. Thank you a lot Mister Bean
anybody has the link for part-2?
a little too wordy in the description, thank you for the effort but actually confused me more
for a moment I thought I was on 2x speed
Ech. That would be super cool to hear more about this in the next episode .... Hope it's going to be created eventually ;) regards
great explanation MAn! Can u explain TDD? Love your videos
Thanks! I'm glad to hear. I can indeed! I'll add it to the todo list :) Thank you very much for the suggestion :)
Let's say you need to do a task in your domain, and you have to implement a method for it. First you write the test that this method needs to pass (using JUnit for example) and then you write the implementation of the method. Hope this helps. :)
OMG! Why did you stop making videos? I'm going to keep commenting here until you start again!
Please!!!!
Mr Bean mastered design principles and became Christopher Okhravi...Great Explanation ...Thank you..
The funny thing is that you had a video on Liskov Substitution Principle posted on July 2016, that was the video that made me discovery your channel.
Haha :) Awesome! Super thanks for sticking around :D :D
If "someThing" can be said about x, then the same thing should be true, when said about y. Where y is a more specific object than x.
Example:
- "Cake is sweet", "Pastry is sweet?" true. Ok LSP holds.
- "In a Rectangle, sides don't have to be the same". "In a Square, sides don't have to be the same?", false. LSP broke.
The name of that symbol is "theta" - it is one of the Greek letters..
----------------------------------------------------------------------------------------------------------
Example:
Where theta is a property, let theta = liquid (the chosen property for theta to represent is "liquid")
Let X (sub1) = water and let X (sub2) = orange juice
Then theta(X sub1) = the liquid which is water
And theta (X sub2) = the liquid which is orange juice
if you have a PARENT class theta(X sub0) where X sub0 = what makes liquid liquid (eg: viscosity, malleability, flow, boiling point) then CHILD class theta(X sub1) and CHILD class theta(X sub2) should each also have viscosity, malleability, flow, boiling point and they be defined identically to theta(X sub0). Any ways that theta(X sub1) and theta(X sub2) differ from one another can not alter the base behavior that defines liquid (viscosity, malleability, flow, boiling point). They can add to that base behavior in a way that makes each child more specific than the parent it inherits from (eg: color, smell, taste) but the base part of that child class that is inherited can not be altered by those extensions. In this way either of theta(X sub1) or theta(X sub2) can be substituted for the parent class theta(X sub0) in any place in the program without failing.
I think
Our brains don't have any problem with this principle when we deal with interfaces. Implementing classes MUST adhere with the behaviors of the interface they implement. For example, a class that directly or indirectly implements that interface must have those implementing methods. For example, any class that implements Sortable interface, must be sortable by definition along with any its subclasses. HOW they sort can be different, but they have to be sortable. You can cheat by having an empty method in any class. HOWEVER, no matter which type or subtype of Sortable you put in the code, you should be able to call the "sort" method. This is why we "code to interfaces" by doing this:
class T implements Sortable {}
class S extends T {}
Sortable x = new T();
Sortable y = new S();
x.sort(); // you could replace anywhere in the code you see that with => y.sort();
y. sort(); // you could replace anywhere in the code you see that with => x.sort();
This LSP in a nutshell!
Gist: The subtype MUST be able to do what its base type can do - Excellent clip! Keep posting good stuff.
One thing I never understood about Liskov Substitution Principle is why it exists? I thought a core part of Object Oriented programming is that if you have a reference to a base class, it can refer to an instance of the base class or any derived class, since all of the derived classes "IS-A" base class. Or is Liskov the person who came up with that principle in Object Oriented programming, and that's why it is named after her? Otherwise, why give a name to something that was already a part of Object Oriented programming to begin with?
It would be like someone deciding to name addition the "Bubba Joe adding principle", when addition already existed before Bubba Joe came along to give addition his name.
Generally, I really like your explanations. They're very clear and down to earth. But I think this time, you might have over-explained it a tad. I mean, I got it the first time. You say there is more depth to this principle, but if you're not going to delve into that in this video, then I don't see the point in going over the same idea again and again.
Hi Chris, really nice explanation, but you know best part @ 5:36 which my daughter of 3.5 years Liked a Lot, She didn't understand the principle but she likes ur expression a lot ...!!!,
Thanks
2020 year, after a lot of videos listening blah blah and blah about Liskov's Substitution, finally understand the Liskov Substitution Principle then I Think this video was awesome need the next one, it's pretty weird that UA-cam is not showing part two on following video, go to authors channel, looking for the part two that never comes.
2 year passed but I'm still looking forward into other letters to be explained
I just recently learned from one of your videos that the snail would speak, but it would have a NullSpeaking behavior that's returned when you run Speak() on the snail.
Next parts please... :(
You expected base class? Haha here is a derived class haha sorry about that. "It's ok i'm Liskov".
Where is part 2?!?!!?!
Holy damn fuck , I finally got it.It is so simple ..Thank you man!
My suggestion to the viewers, If you want to understand exactly what he is talking about, do not fast forward. Listen to the full lecture carefully.
I think for the programming side (Java), that means you should make parent as an abstract class (not an interface), then all child like a snake have to inheritance the speak() function, LSPrinciple breaks when the programmer has no idea what to put inside snake's speak() function
by using the abstract class, we can differentiate between Liskov Substitution Principle (logically child can't speak()), and Interface Segregation Principle(child avoid speak())
If you state something is true about the PARENT type, It HAS to be true all the way down the chain ...
Neat👌
Thanks for the explanation, but I feel like this video could easily have been 2 minutes without the repetition and writing :)
Thanks for the in-depth explanation. BTW @ 7:06 : the symbol is "Phi": en.wikipedia.org/wiki/Phi
interesting thing i understand only example ... common developer thinking :P ....... but this is good explanation.
This is one of the best explanations for this principle that I have been able to find out there. For many of them I would walk away feeling like I understood everything that was being said, but not like a I learned something that I could apply, let alone ideas on how to apply it. I would love for this series to be completed if you have the chance or for you to address the topic as part of another series.
it's 2022
its been 4 years since i commented, still waiting for part 2 :)
I watch many videos to understand about LSP, Finally i am got my inner peace🍻
UA-cam tutorial moment- finding a good tutorial says they'll post part two but never do
I'd really love to see you pick this back up.
This can be too short. I would say start from 7:00 after reading Wikipedia definition.
I really hope that you continue this series.
Or at least start a new one talking about the same topic.
OMG thank you so much I have an exam on Wednesday and I was lost with LSP principle.... I never enjoyed a lesson this much before thank you again
Aha. Great stuff :) How convenient :) :) Best of luck on the exam! 👍👍
Christopher Okhravi I explained LSP to my friends before exam and they were like “oh that’s it 😮 it’s so easy” and I was like “yeah can you imagine “ and then gave them the link to your UA-cam channel 😁
BTW DIP came in the exam not LSP 😂
except that scenario question with classes and DIP example I think I did well
Cristopher!! What will it take to have you create the video about covariance and contravariance ?
I am from the future, Its 2170 and we are still waiting for PART2
10:08 is what you have been looking for .... EXCELLENT !!!
omg, i didn't know mr. bean teach computer science lol.. entertaining video
Never knew Mr. Bean / Rowan Atkinson is a programmer. Great Content bro
The force is with you, all Jedis should be ashamed of themselves! :)
Preparing for exam and this masterpiece is pop up. Great Explanation
It was very easy to understand with the help of your video. Thank you
Christopher would like a part 2 for this video
ppl waiting for part 2 have not still learned L.S.Principle
Hello Christoph, You are awesome. I think I have watched almost all of your sessions on design patterns. This one is also amazing and simplified, but I didn't find the part 2 in this playlist. Could you please help with quick link?
A snail is not an animal. It is a bug. Just kidding. 😊 Bug -> Animal
Hi Chrisopher, Can you please post the 2nd part of this video.
Any chance that you could do a continuation for that video ? Many thanks!
Not sure a dude reading wikipedia on a video is a very sound use of bandwith
Hey We still need you, when you are coming back?
"What pity is it That we can smash, but once on that like button"
Guys, what happened to this channel ??
This guy is fucking amazing!!!! I loved the video and this was the principle I didn't get a all..but watching his video I've understood fully!
Love it! Subscribed!!!
I'm glad to hear :) Kudos to you for sticking with it and thank you for watching :)
Christopher Okhravi ur doing great mate!! Keep up!:)
TL;TW, --> start at 10:09 is enought :)
this guy is so excited hahah
thank you man
You should be preparing it better. 16min!
I don't think it could be explained in a better way.
This video has useful content worth just 2 mins.
Not only a great explanation, this was entertaining as well.
you left me more confused than before I came
I think the only way to violate LSP is using "override" keyword for a method. Therefore if I did not use "override" I'm safe. Do you think it is correct?
Good point. Very interesting. I’m not sure actually. I’m suspecting there’s some further complications around generics (i.e. parametric polymorphism, think T in C#) but I need to learn more before I can have an opinion about this :/ Sorry! But thank you very much for watching the video and dropping a comment!
@@ChristopherOkhravi Thank you for making these videos. I absolutely love them.
really hope to see the next part. You are amazing broo
Just discovered your channel... And my my, What a fine job you have done explaining these concepts. I am from a non-Computer Science Background and even I was able to understand the logic in one go !!
Seems like it's been more than an year that you did the 1st episode... Not sure why you dropped the Series... but like me many would love to see the 2nd and subsequent episodes in this series. 😇
5:30 - This type of error is called a dittography.
Sir you are doing great job and seems you are enjoying it
Bro I been saying this for years, no way.
10:08 Here it starts, the essence. Good luck :)
Woow... That was awesome
Please keep it up.. Great job
And yeah, thanks for sharing.
BTW, I missed that cat 🐈 LOL
I would be careful referring to "has a" as always obeying Liskov's Substitution Principle. If the property of "having a" speak strategy in the animal class is provable then a snail sub-type of animal must also be able to prove that property. So although a snail inheriting from the animal class would not be forced to have a speak strategy it would be incorrect to say it obeys Liskov's Substitution Principle.
Please let me know if I'm on the right track, or if you think there is more to this idea.
Thank You.
And also question - "Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.)"
so if we have class Animal and we have Cat which extends animal. And animal has method speak() which is empty and Cat has method speak() which shows 'miaw' in the screen. But we are altering the property (as I see wikipedia also calls methods as properties) of Animal and break corretness of the program. Lets say correct program was that speak() does not show anything to screen. And when we replaced Animal with Cat - program works incorrectly - shows 'miaw'. So then qestion is - how do we solve this problem that we want cat to say 'miaw' with the speak() method, because it makes sense that speak() method shows 'miaw' but at the same time not break this principle? Or we should not overwrite the methods? THen again - why is this feature in the language?
Thank you! You helped me understand this principle the day before an interview!!
Thank you sir! :) I'll share this with my friends. very helpful.
Yeehaw! Thank you very much :) And thank you for watching :)
Unnecessarily complicating the simple concept.
Thank you for the explanation, Christopher. But, what I don't understand is, this principle is always true in Object-Oriented Programming where a type can be always substitutable by its subtype. Can you, please, provide some examples where this principle is violated. Thx again!!
12:02 - if S inherits from T, how it can not have T methods? It is not possible, at least in PHP. Also I do not understand why you call methods as properties? For me property sounds like class variable. This was confusing.
Or maybe this principle means that you cannot have empty methods. Like if there is parent class called Animal and has method speak. And we create Snail which extends Animal, and automatically snail has method speak() but we make it empty, or it is empty in Animal class - then maybe this is bad?
Also question - if we want Snail to not have method speak, but snail is still animal, then maybe we just remove speak method from the Animal class. And maybe create some class SpeakingAnimal which has speak mehtod() which extends Animal. And since Animal will not have speak() method, we can make Snail extend Animal.
THANKS bro, love from Chile!
When I study I vocalize my ideas similar to how Christopher conducts his presentations. I love the demystification of concepts in order to allow more people to get the job done, and enjoy engineering, no reason to be selfish or arrogant, these youtubers are fighting the good fight I think.
💛💛
i can't find part 2 of liskov's substitution
Very Unique way of explanation, I have see many videos on SOLID principles , this one standout. Great!!!
Love his passion teaching 💞
It's almost 2022 and still waiting for pt2
Please continue making these videos!)