Liskov: The Liskov Substitution Principle
Вставка
- Опубліковано 26 вер 2024
- Barbara Liskov, winner of the Association for Computing Machinery's A.M. Turing Award, discusses the origins, and naming, of the Liskov Substitution Principle which defines the relationship between subtypes and supertypes in object-oriented programming. This clip taken from an interview conducted with Liskov by Tom van Vleck for the ACM on April 20, 2016. Video of the full interview is available as part of Liskov’s ACM profile at amturing.acm.o....
cool to hear real meaning of the principle from first hands. thanks
Great to see a legitimate women pioneer. Who many girls could see for inspiration as sadly many don't have role models to look up to in comp sci/tech.
Wow! Thanks for uploading this! 🙏
One of the heroes that created computing and changed the world forever.
Yeah. What's great is that she's really pragmatic about it, too. She uses plain words to describe it because to her, this isn't some ivory tower principle, it's something she actually understands on a fundamental level.
I feel we're teaching this badly.
Created computing? What age was she? 7? (and I'm being generous, as computing was created long before that)
@@louisfrancisco2171 are you stupid?
2:36 is just pure perfection god I hate confusing internet articles
Tell me about it. Been trying to grok this from other videos and articles. It finally clicked when I heard this explanation.
Beautiful idea, Maam..
This principle is very important to understand
Without this woman, probably i would not able to write this comment.
Big respect to this intelligent lady.
Thank you!
"subtypes behave like supertypes.", short and clear, end al the confusions
thanks
Could someone explain how code could even exist without this principle. Moreover, I dont understand how it would be possible to have either a stack or queue as a method parameter without knowing which it is.
Most of my experience is in Java. Perhaps javas rules prevent you from doing this?
Edit: chatgpt gave an answer which I couldn't have thought of.
Say you have a super type Bird. Then a subclass Ostrich. Bird has a method called fly(). In Ostrich yoy would throw an exception because ostriches cant fly.
That is horrible code and i completely see the value of this principle
Code can certainly exist without this principle. Languages like C do not really provide ways to even describe subtype or super type relationships. It's pretty hard to write code in C where one type is conceptually a subtype of another. I'm honestly not sure how people approach problems that seem best expressed with sub typing relationships in C, but I know it's possible. For instance, if I had a function that needed to take some "collection" (dictionary, vector, or any other kind of collection) and act on every element of it, I could easily express that in Java as a method that takes a parameter of type "Collection". In C, I would (probably naively) create different versions of that function for every concrete type (every implementation of a collection) that I actually wanted to use it with. I'm sure there are better ways, even in C.
The Bird/Ostrich example is neat, thanks for sharing that! At least for that case, Java has at least one feature that can help prevent that mistake: checked exceptions. If the exception in that example does not descend from the class RuntimeException, then you would have to declare the method fly as potentially "throwing" that exception or some super type of it. Because that declaration is part of the method's signature, you would have to declare that property in the signature of the fly method both on the class Ostrich and on the class Bird. So, you'd have something that looks like this in your Bird class:
void fly(/* some parameters */) throws CannotFly {
That means you've declared a fly method on Birds that you can clearly see sometimes fails to work.
I don't think this is always a horrible idea as to how to define things, but it's certainly unintuitive. It doesn't technically violate the Liskov substitution principle here because we've said sometimes a Bird's fly method returns CannotFly - so the definition for Ostrich follows that rule. (I'm following the definition of the Liskov substitution principle here: en.wikipedia.org/wiki/Liskov_substitution_principle).
However, if CannotFly were a subclass of RuntimeException, then this declaration would not be required, and you could more easily violate the Liskov substitution principle without knowing it.
I hope this helps!
@@samuelskean6312 The checked exception is not quite the greatest concept the Java language has ever had, and certainly in this example it's not a solution to using Liskov in Bird / Ostrich.
One could have Ostrich inherit from Bird if you remove the fly() method from it (at first glance that would become a functional interface Flyer (containing only the fly()-method).
Bird could still be useful for Egg layEgg(), void ruffleFeathers(), void peck() and so on, depending on what it's used for. One could argue that even the layEgg-method could be extracted, as non-birds can also lay eggs (so one has to check what's being modeled).
The Liskov-principle is a clear call for being very careful with inheritance and that one should opt for composition instead whenever possible.
can't understate how happy I was when looking up Liskov Substitution to discover this critical idea was conceived by a woman in this catastrophically male-dominated field. we owe so much to the intelligence of women like Liskov, Hopper and Margaret Hamilton, and we should do everything we can to destroy every last vestige of bigotry in this industry, so everyone feels welcome to explore and improve computing
what? what bigotry? gender has nothing to do with it lol it's not like there's a system preventing them since waaay back 1930s there was Mary cury etc female scientists well recognised. STOP PRETENDING LIKE WE'RE SOME TYPE OF PATRIEARCHY it is what it is when women are smart and invent something it's immediately recognised period we shouldn't even have a debat about genders totally meaningless SCIENCE IS THE ABSOLUT nothing else don't involve it in political squabls
Women started the field of software development from the ground up. It didn't become male-dominated until the mid-80 with the advent of personal computers, computers that were marketed to men and boys and that parents never bought for girls. Using one became prerequisite knowledge for college.
OMG don't swallow the propaganda, it's nobody's fault that it's "male dominated", many women are awesome at Software Development, they simply don't like it as much as other things. It may be truth that there was marketing made towards men in the 80s, that's almost 40 years ago and the trend continues in this digital era where many has access to technology. Also you see the same trend in many countries where this sort of publicity wasn't predominant or didn't exist at all.
Is she Barbara Liskow?
No, that's me
i don't know why but this is so wholesome
Anonymous coward.
"Behavioral Subtyping" (subtypes behave like supertypes) is much more intuitive than "Liskov Substitution Principle"!!
i have huge respect for Barbara Liskov and her intellectual clarity, and her contributions to computer science should definitely be remembered, but it's also very important that we keep *everything* in CS as intuitive and simple as we can manage to, and that absolutely must include the names we use for things! "behavioral subtyping" is indeed a better name. it's ironic that it's the name she gave it, too, haha!
I am gonna call it SOBID priciples now. 99% engineers can intuitively remember the usages and meanings of S O I D but not the L, because S O I D are intuitive names.
100% agree!
@@gloverelaxis I'm pretty sure she didn't name it after herself.
AMAZING
A very simple explanation she said - Behavioural subtyping - subtypes behave like super types 👍👍
that's not what she said at all!
@@jja77a : watch the video once again from 4:05.
You can apologise later 😂
Is that super?
Sorry, I know absolutely fuck all about programming languages. I don't even know how I ended up here... I must be a Subtype, following the lead of the Supertypes, yeah? :D
No? Hm...
Oh! One thing I'm REAL good at is getting software to glitch out, so... Anyone need a tester to thoroughly break what you've built? :D
This is THE explanation from the CREATOR, so sad other videos on this subject have more views
Subtype behaviour like SuperType
How much confusion there is out there about this principle.
So ummm. Liskov is woman ?. I tought she is man
thinking about why you thought that is something for you to think about, innit
cheers matr
Come on man, don't show that you didn't pay attention so much that you didn't some googling on the subject
Finally! I understand. Thank you for sharing this video!