Liskov's Substitution Principle | SOLID Design Principles (ep 1 part 1)

welcome to this series on the solid design principles wait the s oli the solid design principles of object-oriented programming so s for single responsibility principle o for open closed principle l for Liskov substitution principle I for interface segregation principle and D what D stand for ah dependency inversion principle silly of me but today we are going to talk about the L here L as in Liskov substitution principle and if you've ever read about it before you're like well just reading the name Liskov substitution principle it's kind of like an instant brain explosion you're like who chose the word substitution like substitution principle like what does even a principle of substitution mean but actually if you if you dig down and you try to start to understand this curve substitution principle you calmly try to just read it and think about it it's actually very simple and like once you get it you're like but isn't this blatantly obvious which it kind of is right but the thing about Liskov substitution principle which I find particularly interesting is that it's one of these things in programming that are very very well-defined like there is more what we did in just a moment there is a logical definition of what strictly what it means for something to follow Liskov substitution principle now still there's a lot of room for interpretation and semantics a lot of room and we'll get into that but still at least there is a rigid definition which from many things there or not right like single responsibility principle for example right like what does even doing a single thing mean like that that's super a poor interpretation very very much up for interpretation and even though there is interpretation or room for interpretation in risk of substitution principle there's less room for interpretation so let me just write the name here what we're talking about is Liskov substitution substitution principle this were talking about this called substitution principle and clearly the the the person who invented the scoff substitution principle was named disco let's read the definition from Wikipedia so prepare yourself for another mind blow 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 in other words an object of type T may be substituted with any object of subtype s hence the name substitution by the way without altering any of the desirable properties of T correctness tasks performed etc right this is like okay so I have to know logic you know this because I have to know but like use this strange notation of like SS and T's and types and but not stick with me it's actually pretty simple we'll talk about it and then there's this other sentence that says more formally the Liskov substitution principle is a particular definition of a subtyping relation called strong behavioral subtyping that was initially introduced by ah here it comes Barbara Liskov let's go hence Liskov substitution principle in 1987 actually in a conference keynote address titled data abstraction and hierarchy that was given this and his keynote was given in 1987 okay I was born in 97 booyah here's the really interesting part you know I said it does allow for some wiggle room or some room for interpretation here's that interpretation part it says this is or it is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy and then actually here's here's the principle in the way they've formulated it in a paper that Liskov and then somebody called jeanette wing published and this definition is actually not that strange so let's start in that end it's a bit like logic heavy so you have to put your like scientist hat on and go okay I shall now read logic and I shall not be intimidated by it but let's go let me remove this stuff so here's the quote from the paper it says here's the subtype requirement require mint subtype requirement so they're saying what if there is some property provable of some some X let this made-up hypothetical pretend property that this property of X so let this thing of X be a property be a property provable about objects X of type T then let me just type this out and then we'll talk about it then this property of Y should be true be true for [Applause] objects Y of pipe s where s is a subtype hang on hang on hang on I know brain explosion sorry where s is a subtype of P oh yeah terrible right but actually it's completely logical I know this sounds like gold gibberish but they actually makes complete sense let's do this let's the first thing about it this way so what do we got we've got this important thing or actually let's do this thing we've got X's let me put these in red we've got X here we've got X here and we yeah that's it right we don't have any more X's no now let's take green then let's just say we have Y's right we have Y here and we have Y here and yeah that's it and then what then we have T I'm running out of colors this is a bad idea let me do it let me do it this way y x and y are variables right so so let me say those are red so why here and why here and we have types so let me put those in in green so there's the type T here and then there's the type s here and here s and s and actually s here as well s and then there's T here T and that's it right yeah now let's take blue and make this property blue so there's this property also property here and this property here and that's it right yep so those are all the sort of magic words right those are all the key words so so let's let's let's now read this and let's think about it so here's the thing what they're saying is that there is this hypothetical arbitrary property something something right let's call it circle o the symbol probably has a name but who cares there's there's a symbol an object can have this property so an X which is any object right it's it's an animal instance in your object-oriented system it's it's a an instance of a user class it's an instance of a resource manager it's an instance of a factory it's an inch an instance of whatever you have in your system right so so X is something and the thing is that when we say it's an instance of something right that something is of a type so if it's a user for example then the user is the type so user is the class and then we have an instance and what we're talking about here when we say X we say we're talking about probably collections because it's plural somewhere when we say objects but in order to simplify let's just think about it as as a single thing so this X represents an instance of something of a type and in order to talk about all types at the same time we are talking about T's this is why we have these these two green things we're talking about T's and we're talking about SS and T's could be the same as SS it could be but it could also be different so T is one type could be animal and s is another type could be user or it could be any other class and it's it's it's generally and then XS are something of some kind of type it's some kind of instance and the same goes for YY is also a variable that represents an instance of some kind of class and then what we're saying is that this blue thing the the the the circle says that an object can have a property and this might be the thing about it this way it could be like responding to the method speak I guess is well kind of what they mean here so if is an instance of an animal and so its type is animal and animals have a method which is speak then this property could be this speak method so the only thing that this this whole mess is saying right is that if there is an X and X has this circle property so if you think about a classically object oriented if you think thinking about classes right so so T is a class T defines a method and that means that all instances if there are instances of T then that means they have this method right this is all we're saying so X is RTS and they have this property but they're saying that if that's the case then it should be the case that all wise so another instance of another class they should also have this property should be true and for objects of Y if these wise or of type s we're type s is a subtype why I just realized I'm an idiot I wrote the same sentence two times so here it says where s is a subtype whereas is a subtype of T so I'm sorry let's let's just remove this stuff where s is a subtype of T that's why I'm N sorry about that see even like piping it from the text makes me super confused anyways so we're saying that wise should to have this property if wiser of type s and s is a subtype of T let's throw this in your mouth let's think about it this way so you have if two classes where one class inherits from the other class so you have the type T and then you have the type s should have used the green again to emphasize that these are the types but you have T up here and then you have type s and so type s is a subtype of type T it is a T and the only thing we're saying here is that if there is something that T is do right there's there something there's some method that the T responds to there is there something that T's can do then necessarily SS must be able to do that subtypes must be able to do that same if not I mean why are we then saying that s is a team and that's the whole point right so this is what they're digging down into there they're trying to show us when we should not use inheritance and when we should use inheritance so if you've got a cat which is an animal and animal speak then cats necessarily speak right but if you have actually this is a very good example because if you think about it not all animals speak right so if we're modeling the whole world for most of the time we're not which is why we don't have to think about those scenarios but if we are modeling like tons and tons of animals let's think about an animal that doesn't speak I mean snails maybe don't speak but they're still an animal so that means that we would be breaking Liskov substitution principle because we're saying that a snail inherits a snail inherits from an animal and animal speak but snails don't speak that makes no sense we can say a snail is this thing and to be of this thing you need to have this property but suddenly this thing that we just created this name doesn't have this property it makes no sense and that's what they're trying to stop us from doing so that gives you an excellent way of thinking about inheritance you have a type and then you have subtypes of that type you have some kind of concept and then you are saying that things can be of this concept there is the notion of being some particular thing and some of these things are this thing right yeah you have this hierarchy of of being right like you could have animal and then mammals and then some subtype of mammals I'm sorry biology is not necessarily my strong side but you know you realize this this whole chain right and when you're traversing down this chain it's super important that whenever you state that something up here in the chain has some kind of property something up here does something then everything downwards has to submit to that property or has to has to adhere that has the respect the existence of that thing has to so back to their statement has to be if if this O is a property provable by objects or about objects on X then everything down the chain everything down the inheritance chain it needs to be provable for all of those as well right because otherwise you can't say it is of that type and this is during the key notion and this is I mean think about it this is why we talk about composition over inheritance because most of the time we are really looking for a composition because we're making two general statements we're saying that ah all of the animals can speak but actually all the animals cannot and the really dangerous part is we think that we have identified all of the subtypes of animals that we will see in our system and then we get new requirements and then we realize ah okay actually we missed a few and then suddenly we may end up in a situation where we're breaking risk of substitution principle if we're not refactoring and this is why we're talking about composition over inheritance compose things use the notion of Hazza rather than is a-- because Hazza is much less troublesome right of course and when you say has a-- and that thing that you have has its own inheritance higher has its own inheritance chain or an inheritance hierarchy then of course you have you still have the Liskov substitution principle applied to that inheritance hierarchy but that's because that's an inheritance hierarchy right just a hazard relationship doesn't have this problem but yeah so so in summary the really simple way to think about this is that you have two types and the parent type if you state that something is true about the parent type it has to be true all the way down the chain if you state that the parent type can do something all subtypes need to be able to do that too there's a lot more depth to the Liskov substitution principle this is just part one in the next video we will talk about Contra variants and Cole Maryann's you know like the stranger is just keep on piling up contravariance and covariance and then in the next video we will talk about design by contract right there's there's some and this is really where we get into this sort of semantics of Liskov substitution principle so we will talk about things that you might have heard before preconditions post conditions and invariants so preconditions are things that have to be true when executing a method for example it's like upon entering a method what has to be true before that method is lickable post conditions are what needs to be true as we exit the method and invariants are things that always have to be true like within a class for example like during the lifetime of this of an instance of this class this invariant rule is this something that stated as an invariant can never be broken and these help a lot when thinking about what Liskov substitution principle actually means in depth like when we say this whole thing like let all be a property of X that buh-buh-buh-buh-buh like this this whole thing that's fine and dandy but there's a lot more nuance to it and this is what we're gonna talk about in these two videos possibly I'll do it in the other order because I think this makes a lot more sense and I have to read up a bit on the contravariant covariance maybe even the same video Multi sorry for splitting in this video into two I ran out of time I hope this first portion made sense I hope you now feel that Liskov substitution principle is a little bit less intimidating thank you super much for watching remember to subscribe and I'll see you in the next one

Channel: Christopher Okhravi

Views: 109,655

Rating: 4.708601 out of 5

Keywords: liskov substitution principle, liskov's substitution principle, liskov, substitution, LSP, SOLID, design principles, solid design principles, OOP

Id: ObHQHszbIcE

Length: 16min 8sec (968 seconds)

Published: Mon Oct 16 2017