Excellent explanation! As always. Never stop! To me, its definition was helpful. Great definition: Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
Christopher, initially bit confused in understanding liskov , your summary regarding interface usage really helped me to clear all the confusion Thank you. very much. and impressed in your out of classroom teaching :)
The explanation of pre/post conditions using sets diagrams was really helpful! Really nice to watch by the way, not hard at all to concentrate as the camera is unstable but mainly focused in the information, in this case you :D
Great video, thanks Christopher. Like most concepts in software development, being able to experience the information in different forms (be it whiteboards, practical, code along or walking explanation) it really helps to reinforce ideas. Thanks again!
Great videos ,really enjoyed the Design pattern series . I got question on this video (at 5:53) , how to make subtype accpet same or more pre-condition in Java,as contravariance is not allowed in method arguments in java method overriding??. I understood post-condition of a subtype can be weaker as Java supports covariance in return type . Also, please share an example of invariance in same context of method overriding ?? Sorry for java biased question ,even pseudo code will help understand these concepts.
The Liskov Substitution Principle is pretty Superfluous and without relevance in my opinion. Why ? Well, the principle (or better, one of the principles) of OOP is that you use inheritance to specialize base classes. Using inheritance, an object of the subclass contains an internal (in-memory) object of the base class, which will be the only part of the whole object available if you address such an object using a base class reference. Since then it indeed is an object of the base class, it of course is interchangeable with such. That means, that a subclass always has to be more specialized than its baseclass, or in other words, must have additional content - may it be data members or methods or both. So, a subclass cannot be identical to its baseclass, it always has to provide some additions. Since these additions cannot be part of the baseclass (or the whole sense of inheritance would crumble), an object of a subclass can never "replace" an object of the baseclass in full sense, meaning you would render the additions useless. Subclass and baseclass therefore are only directly comparable and interchangeable if you limit their use to the members the baseclass provides. This limits the applicability of Liskov principle to the lowest common denominator and therefore will be useless in most cases. A different aspect is overloading virtual methods of the base class. If overloaded correctly, they are interchangeable with their virtual counterparts of the base class, but may show different behaviour. But they have the same return type and the same parameters. If an overloaded method would be identical to the virtual base method (given the base class method is not abstract, which is a different case where we speak of implementing an abstract method prototype), it would not make any sense to overload it at all. If "overloading" the inherited base method results in a different return type or different parameters of that same method, this would not be an overload of the base function. This would indeed violate the Liskov principle since they could no longer be usable identically. If you omit the "virtual" keyword in the base class method and replace the inherited method with a new, identical one (identical return type and parameters) this would not really overload the base class method, but instead conceal it. Thus, both methods exist in parallel. Only the type of reference you use would determine which method you get. Also, a method you overload may not have a stronger access-attribute (base class method public, subclass method private) or the method would be less accessable than the base class method and would rherefore violate the Liskov principle. If you use inheritance correctly, you will never have a problem with liskov principle, as long as you limit yourself to the use of the base class methods. And honestly, why should i ?
Man, your videos are awesome, all of them I have watched them and I’m very happy with your content, the problem is that you just stop, there are hundreds of people like me trying to reach you to tell you, please do more, even if they are paid videos I will give you my money, you can sell them Udemy, patron or TH-cam itself. I will be very grateful, but not only me, a lot of people. Thanks!
Thank you for the kind words. I had to take a break in order to finish up my PhD. Hopefully I’ll soon be done and on the other side. Then I will return 😊 Thank you again. Much appreciated.
Lets say that the subclass only has a constructor method and inherits all of its other methods through an abstract class. Would this subclass satisfy the LSP as long as it contained all the necessary types of arguments found in the abstract classes methods?
I'd say maybe yes, maybe no. It all depends on what the provable properties of the parent class are. In general, behavioral subtyping is undecidable. So finding out that some class is breaking LSP is a lot easier than proving that some class satifies LSP.
Box being forced to implement Walk method is a violation of Interface Segregation Principle (no client should be forced to depend on methods it does not use)...isn't it?
instead of weaker and stronger, i would use the words broader and narrower - this way, the saying stands on its own without needing extra clarification.
Thanks for letting me know! :) My newer videos are more calm since they're filmed in front of a whiteboard. I'll make sure to make a whiteboard video that tackles the same concepts as this video. I appreciate the feedback :)
:D :D My understanding is that it is not punishable in Sweden, unless carelessly carried out. But I appreciate you looking out for me :D Thanks for watching.
Awesome video. And thanks. It make a lot of sense. Oh, one other thing, you say you are not religious right? Well, this saying is true: "Jesus Christ will save you from Hell fire" So follow him.
All these SOLID principles are not something new. We call them before, common sense at the time you are programming. Now somebody gives them a name, making them more confusing.
Don't wanna sound like an ass or anything but what is the point of the background video? Voice and the notes you added anyway were more than enough. The remaining video is mostly a hindrance and a constant distraction.
Actually the robustness principle is horrible in my opinion. I think you should rather be less accepting and make sure that you fail fast if you get incorrect values. ESPECIALLY in network protocols. Because if you accept more, it gets much much harder to change your code later on and then you're stuck for eternity.
I agree. I wasn’t aware of this position when making the video though. 😊😊 You might be interested in my other video on that topic: th-cam.com/video/1B4KjAhQJoQ/w-d-xo.html Thank you for your very valid input! 😊😊
![ค้างคืนโรงเก็บกระสวยอวกาศร้างกลางทะเลทราย [Around The World Ep. 3]](http://i.ytimg.com/vi/E5bWZQhABJE/mqdefault.jpg)
Maybe it is the best explanation I've ever met. Thanks a lot!
Thank you for taking the time to letting me know :) I'm glad the video is useful.
Excellent explanation! As always. Never stop!
To me, its definition was helpful. Great definition:
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
Christopher, initially bit confused in understanding liskov , your summary regarding interface usage really helped me to clear all the confusion Thank you. very much. and impressed in your out of classroom teaching :)
Great! I'm glad. Feel free to ask if something is still confusing :)
This is 6 years ago, it's still relevant and informative.
I'm in love with this channel. I never knew i could learn so fast in one video each..
The explanation of pre/post conditions using sets diagrams was really helpful! Really nice to watch by the way, not hard at all to concentrate as the camera is unstable but mainly focused in the information, in this case you :D
+José Ignacio Toledo Navarro Solid. I'm glad. I myself thought the sets turned out quite well so I'm very glad you pointed it out :)
+José Ignacio Toledo Navarro And thanks for watching :)
thx to you for the good material! +1 sub ;)
Great video, thanks Christopher. Like most concepts in software development, being able to experience the information in different forms (be it whiteboards, practical, code along or walking explanation) it really helps to reinforce ideas. Thanks again!
Very Interesting perspective of LSP and very useful too. Please keep up the good work !!
Great videos ,really enjoyed the Design pattern series .
I got question on this video (at 5:53) , how to make subtype accpet same or more pre-condition in Java,as contravariance is not allowed in method arguments in java method overriding??. I understood post-condition of a subtype can be weaker as Java supports covariance in return type . Also, please share an example of invariance in same context of method overriding ?? Sorry for java biased question ,even pseudo code will help understand these concepts.
such an amazing explanation !
Great explanation, and great view behind as well. :)
The Liskov Substitution Principle is pretty Superfluous and without relevance in my opinion. Why ?
Well, the principle (or better, one of the principles) of OOP is that you use inheritance to specialize base classes.
Using inheritance, an object of the subclass contains an internal (in-memory) object of the base class, which will be the only part of the whole object available if you address such an object using a base class reference. Since then it indeed is an object of the base class, it of course is interchangeable with such.
That means, that a subclass always has to be more specialized than its baseclass, or in other words, must have additional content - may it be data members or methods or both.
So, a subclass cannot be identical to its baseclass, it always has to provide some additions. Since these additions cannot be part of the baseclass (or the whole sense of inheritance would crumble), an object of a subclass can never "replace" an object of the baseclass in full sense, meaning you would render the additions useless.
Subclass and baseclass therefore are only directly comparable and interchangeable if you limit their use to the members the baseclass provides.
This limits the applicability of Liskov principle to the lowest common denominator and therefore will be useless in most cases.
A different aspect is overloading virtual methods of the base class.
If overloaded correctly, they are interchangeable with their virtual counterparts of the base class, but may show different behaviour.
But they have the same return type and the same parameters.
If an overloaded method would be identical to the virtual base method (given the base class method is not abstract, which is a different case where we speak of implementing an abstract method prototype), it would not make any sense to overload it at all.
If "overloading" the inherited base method results in a different return type or different parameters of that same method, this would not be an overload of the base function. This would indeed violate the Liskov principle since they could no longer be usable identically.
If you omit the "virtual" keyword in the base class method and replace the inherited method with a new, identical one (identical return type and parameters) this would not really overload the base class method, but instead conceal it. Thus, both methods exist in parallel.
Only the type of reference you use would determine which method you get.
Also, a method you overload may not have a stronger access-attribute (base class method public, subclass method private) or the method would be less accessable than the base class method and would rherefore violate the Liskov principle.
If you use inheritance correctly, you will never have a problem with liskov principle, as long as you limit yourself to the use of the base class methods. And honestly, why should i ?
Thx, that's my point too.
thanks for the explanation. may i know where do you live?
+Kapten Laut Uppsala, Sweden :) Thanks for watching! :)
great explanation and great energies.
Haha thanks! I'm glad :)
Easiest explanation ever!
5:09 I was thinking exactly the same and he spoke the exact words. wow...
Man, your videos are awesome, all of them I have watched them and I’m very happy with your content, the problem is that you just stop, there are hundreds of people like me trying to reach you to tell you, please do more, even if they are paid videos I will give you my money, you can sell them Udemy, patron or TH-cam itself. I will be very grateful, but not only me, a lot of people.
Thanks!
Thank you for the kind words. I had to take a break in order to finish up my PhD. Hopefully I’ll soon be done and on the other side. Then I will return 😊 Thank you again. Much appreciated.
Here is another of his videos on Liskov's Substitution principle, sadly he hasnt made part 2 yet. th-cam.com/video/ObHQHszbIcE/w-d-xo.html
Thanks, Was searching
Lets say that the subclass only has a constructor method and inherits all of its other methods through an abstract class. Would this subclass satisfy the LSP as long as it contained all the necessary types of arguments found in the abstract classes methods?
I'd say maybe yes, maybe no. It all depends on what the provable properties of the parent class are. In general, behavioral subtyping is undecidable. So finding out that some class is breaking LSP is a lot easier than proving that some class satifies LSP.
the golden rule reference cracked me up! :D
It's really simple. It boils down to, "Don't inherent crap you're not going to use."
what is an example of an invariant?
Box being forced to implement Walk method is a violation of Interface Segregation Principle (no client should be forced to depend on methods it does not use)...isn't it?
It would be perfect if you could make the same series of videos but this time explaining all the stuff on a white board
instead of weaker and stronger, i would use the words broader and narrower - this way, the saying stands on its own without needing extra clarification.
Great Explanation !
Great work bro :-)
+AboAlbaraa Mohamed Thank you very much. I'm glad you appreciate it :) Thank you for watching.
Cool Video.
Thanks! I'm glad it's appreciated :)
You Sir - You are Brilliant, Bravo!
Thank you for the kind words :) I'm glad the video is useful :)
Too confusing and difficult to focus
Thanks for letting me know! :) My newer videos are more calm since they're filmed in front of a whiteboard. I'll make sure to make a whiteboard video that tackles the same concepts as this video. I appreciate the feedback :)
Yes please, no more walking videos :-)
Keep up the great work btw
did you just jay walk?
:D :D My understanding is that it is not punishable in Sweden, unless carelessly carried out. But I appreciate you looking out for me :D Thanks for watching.
Thanks for the videos, it helps me rebuild my rusty software engineering skills
amazing!! :D I think I will make your same video in spanish :v (but maybe I should include some ducks)
+TheCaliscool1 ducks always help! :) :) Btw subtitle contributions are always welcome!
Thank you
And thank you for watching :) Glad it helps :)
dude ur awesome
5:04 exactly what I thought.
Awesome video. And thanks. It make a lot of sense.
Oh, one other thing, you say you are not religious right?
Well, this saying is true: "Jesus Christ will save you from Hell fire"
So follow him.
You broke the complex into much simpler form.
All these SOLID principles are not something new. We call them before, common sense at the time you are programming. Now somebody gives them a name, making them more confusing.
I don't like these videos that made outside! It's too noisy and hard to focus!
Don't wanna sound like an ass or anything but what is the point of the background video? Voice and the notes you added anyway were more than enough. The remaining video is mostly a hindrance and a constant distraction.
😵🤯😅
Actually the robustness principle is horrible in my opinion. I think you should rather be less accepting and make sure that you fail fast if you get incorrect values. ESPECIALLY in network protocols. Because if you accept more, it gets much much harder to change your code later on and then you're stuck for eternity.
And thanks, you were the person that made me understand the Liskov Substitution principle in your other Video about it!
I agree. I wasn’t aware of this position when making the video though. 😊😊 You might be interested in my other video on that topic: th-cam.com/video/1B4KjAhQJoQ/w-d-xo.html
Thank you for your very valid input! 😊😊