What is an example of the Liskov Substitution Principle?

Asked 11/9, 2008 at 15:17 Answered 14/12, 2021 at 23:53

Solved oop definition solid-principles design-principles liskov-substitution-principle

1234

I have heard that the Liskov Substitution Principle (LSP) is a fundamental principle of object oriented design. What is it and what are some examples of its use?

Boys answered 11/9, 2008 at 15:17 Comment(5)

More examples of LSP adherence and violation here – Peden 15/5, 2015 at 13:20

This is one of the best examples I have found: baeldung.com/java-liskov-substitution-principle – Rowlandson 19/3, 2022 at 23:39

The Liskov Substitution Principle states that subclasses should be blindly substitutable for their base classes. – Calistacalisthenics 10/6, 2022 at 11:40

The Liskov Substitution Principle states that subclasses should be blindly substitutable for their base classes. – Calistacalisthenics 10/6, 2022 at 11:44

The Liskov Substitution Principle states that subclasses should be blindly substitutable for their base classes. – Calistacalisthenics 10/6, 2022 at 11:45

1233

A great example illustrating LSP (given by Uncle Bob in a podcast I heard recently) was how sometimes something that sounds right in natural language doesn't quite work in code.

In mathematics, a Square is a Rectangle. Indeed it is a specialization of a rectangle. The "is a" makes you want to model this with inheritance. However if in code you made Square derive from Rectangle, then a Square should be usable anywhere you expect a Rectangle. This makes for some strange behavior.

Imagine you had SetWidth and SetHeight methods on your Rectangle base class; this seems perfectly logical. However if your Rectangle reference pointed to a Square, then SetWidth and SetHeight doesn't make sense because setting one would change the other to match it. In this case Square fails the Liskov Substitution Test with Rectangle and the abstraction of having Square inherit from Rectangle is a bad one.

Y'all should check out the other priceless SOLID Principles Explained With Motivational Posters.

Airlike answered 25/2, 2009 at 4:44 Comment(43)

@Airlike What if it's an immutable Rectangle such that instead of SetWidth and SetHeight, we have the methods GetWidth and GetHeight instead? – Durtschi 26/4, 2012 at 19:28

Moral of the story: model your classes based on behaviours not on properties; model your data based on properties and not on behaviours. If it behaves like a duck, it's certainly a bird. – Unison 19/5, 2012 at 21:43

Well, a square clearly IS a type of rectangle in the real world. Whether we can model this in our code depends on the spec. What the LSP indicates is that subtype behavior should match base type behavior as defined in the base type specification. If the rectangle base type spec says that height and width can be set independently, then LSP says that square cannot be a subtype of rectangle. If the rectangle spec says that a rectangle is immutable, then a square can be a subtype of rectangle. It's all about subtypes maintaining the behavior specified for the base type. – Invaluable 24/9, 2012 at 15:46

@Durtschi there is no issue if it's immutable. The real issue here is that we are not modeling rectangles, but rather "reshapable rectangles," i.e., rectangles whose width or height can be modified after creation (and we still consider it to be the same object). If we look at the rectangle class in this way, it is clear that a square is not a "reshapable rectangle", because a square cannot be reshaped and still be a square (in general). Mathematically, we don't see the problem because mutability doesn't even make sense in a mathematical context. – Sydney 20/1, 2013 at 6:13

From Prof Barbara Liskov's lecture: "Objects of subtypes should behave like those of supertypes if used via supertype methods." – Unreligious 4/2, 2015 at 6:9

If width and height can be altered by setters, there should be just a rectangle class and no special square class. Instead, the rectangle class should have a getter that is named IsSquare. Whenever width and height have the same values, IsSquare will return true, otherwise false. Types are not always static, but sometimes - like in this case - can change. – Goatskin 10/2, 2015 at 10:53

so why i even need subtyping if my inherited class's behaviour doesn't differ from parent (excluding cases, when it does the same but different way)? why one need all those override methods if they have to behave absolutely similarly to base's? speaking of geometry figures: IDrawable has Draw(). how could you insist Circle:IDrawable's Draw() give the same result as Square:IDrawable's? or, say, Rotated90DegreesSquare:Square draw the same as square? – Susette 11/9, 2015 at 5:3

I have one question about the principle. Why would be the problem if Square.setWidth(int width) was implemented like this: this.width = width; this.height = width;? In this case it is guaranteed that the width equals the height. – Pressing 28/10, 2015 at 0:45

That Motivational Poster makes no sense. It should be "If it looks like a Duck, Quacks Like a Duck, But Needs Batteries ... why are you interested in the Batteries, again?" Because in the end it implies that the only substitution for a duck is another duck (best the exact same one). Such radicalism is self-defeating. – Ironstone 5/1, 2016 at 15:49

The Square-Rectangle Problem is also known as Circle-Ellipse Problem. – Catechin 2/3, 2016 at 7:42

The right or wrong, good or bad, depends on one's perspective - whether it is from code consumer side or from the code author side. LSP, IMO, applies to the consumer side. Put in right perspective, many wrongs look right. – Reckon 23/5, 2016 at 12:42

Another solution is to define rectangles as aspect-ratio preserving rather than as having independent widths and heights. – Valona 16/7, 2016 at 1:23

Seems to not answer the question. After reading it, I still don't know what LSP is (unless the poster contains the definition, though given the context of such posters, this is not clear). – Atrice 12/8, 2016 at 17:58

I also don't get the square example. How does setWidth and setHeight not "make sense" on a square. As you very easily explained, doing one implies the other - that's just the definition of a square. It doesn't explain why there is something wrong or inconsistent with substituting a square for a rectangle. – Atrice 12/8, 2016 at 18:3

Couldn't you simply override setWidth or setHeight, and in the definition call the other method with the same parameter and poof, it all works and behaviour is consistent? – Paulita 22/11, 2016 at 5:48

@MCEmperor if you change the implementation of setHeight() and setWidth() in the Square, so the places in your code where you use a Rectangule would not work anymore if you pass a Square and this is the main point about LSP; – Cetacean 26/12, 2016 at 3:12

Thank you for your answer - but so what if the LSP is broken? – Gereron 2/1, 2017 at 13:30

However, the picture is NOT a valid example of a broken LSP (smells of Reddit actually, and that is not something we want to smell here on SO). Subclasses will always be more specific than superclasses. However, their specifics do not necessarily break LSP. It is a question of whether these specifics affect (and break) the common contract. Whether a battery-powered duck breaks the common contract of an abstract duck depends on the specific details of the design. – Cobol 28/1, 2017 at 1:57

Everyone uses this square vs rectangle which such a horrible example. You're overriding the Width Property to set the Height Property, Which seems more like side effect. This would all be solved if you made people explicitly set the width and height. – Elysha 28/2, 2017 at 22:41

The o.setDimensions(width, height) would solve that problem, but LSP still would be violated, because a square has stronger preconditions (width == height) than a rectangle. I don't think your post answers anything about LSP. – Jenness 9/10, 2017 at 3:48

There is a good complementary information about method override / contracts here softwareengineering.stackexchange.com/a/244783/1451 – Pulpy 21/10, 2017 at 10:6

Is a rectangle a type of square or is a square a type of rectangle or the other way around? A rectangle can be defined as a square with unequal sides and a square can be defined as a rectangle with equal sides. A square with unequal sides is not a square, but a rectangle with equal sides is still a rectangle and a square. So a square is a rectangle with an additional contract. Therefore, the interface for a square should be the same as one for a rectangle. Setting one dimension should set the other makes perfect sense. – Plessor 15/12, 2017 at 20:33

I wouldn't say there's no issue if they're immuatable. It could throw a reader off to see GetHeight and GetWidth if they're going to do the exact same thing. That might by a tiny issue, but still a reason to do it another way. – Apocarp 8/5, 2018 at 23:45

İs it calls %100 rule in some books? – Ultann 17/6, 2018 at 11:25

@Apocarp no, these are well defined quantities. A square has both a height and a width; they happen to be equal. If the reader is thrown off by this then they either learn something new and important about the code or they don't belong there :) – Irvingirwin 19/6, 2018 at 19:18

I think that we are confusing sub-type with "particular case". A square has nothing different in behavior compared with a rectangle. The perimeter, area can be calculated using the same formulas. Square is not an improvement or refinement of a rectangle, it's just a particular case. Square shouldn't be a subclass of a rectangle, it shouldn't even be a separate class. – Gorizia 5/2, 2019 at 3:17

@MirceaIon, Square could be a subclass of Rectangle to simplify the interface, eg with SetLength which could internally call SetWidth and SetHeight – Whomever 29/3, 2019 at 16:16

Its OK to derive Square from Rectangle, but you should not have setWidth and setHeight in the case. But no one could prevent you to have setters for a zone there you put the rectangles. In the case, Square will fill only part of the zone, while Rectangle will fill it completely. :) – Halfblood 17/4, 2019 at 16:45

Can someone please, for the love of code, tell me how else to model this same example then so that it follows LSP? – Weaponry 11/6, 2019 at 15:50

Once I have failed an interview on this exact question about squares. The interviewer rejected my immediate question: "What are we going to do with those rectangles and squares?" Today I'm happy I hadn't got that job. :) – Potto 15/12, 2019 at 12:38

Which uncle Bob? :-? – Jinni 5/2, 2020 at 16:18

@Cetacean I disagree. Can you name one situation where if you have the behavior of setHeight and setWidth overwritten in the Square class like MCEmperor signed that the code would not work for Reactangle anymore? – Gradate 9/4, 2020 at 1:40

It would've been much much better to provide some exemplifying use-case and a snippet, which would've demonstrated code. – Italic 5/8, 2020 at 21:54

@Gradate It needs to fill our 640x480 box, so r.SetWidth (640); r.SetHeight(480), or vice versa, makes no difference. Any subclass that offers the ability to set width and height separately but doesn't actually do so is going to break things. – Night 13/1, 2021 at 1:28

The problem I find with SetWidth and SetHeight methods is that they're not only breaking LSP but also ISP (Interface Segregation Principle), So they should be segregated in two different interfaces maybe SetSize(int, int) for Rectangle and SetSize(int) for Square, because they're different, Getters might stay where they are... open to discussion – Libb 28/1, 2021 at 11:56

Regarding the duck, batteries and why it breaks LSV -> because ducks, by definition, do not need batteries. For me, it is pretty obvious and it is a metaphor in the form of a joke, not to be taken more seriously than that. – Beccafico 17/3, 2021 at 17:4

@SaurabhGoyal - the point is that the correct implementation should not have side-effects of one getter to another property, since the parent did not have them in the first place. For example, you could not have getters for individual height and width and have then as a pair, and a single setDimentions(x,y) and that way you could avoid this specific side-effect of changing height when setting Width in the square example. There are for sure multiple ways of achieving this. The main point is that the behaviour of the child would differ from the parent. That is what breaks the LSP. – Beccafico 17/3, 2021 at 17:10

In response to @asmeurer, I think it's a bit of a cop-out to say is-a only didn't work, because we should have been thinking of these as "reshapable squares/rectangles". What if I have a Car class with an addGas() method, and I want to add an ElectricCar class? An ElectricCar certainly is-a Car, but you can't follow LSP here. The real problem is that "is-a" is trying to make judgement calls based on English intuition and class names only, but you must also consider the behaviors of the class. LSP does this. is-a does not. – Akene 15/6, 2022 at 2:26

You could add asterisks to the is-a rule to say you're required to consider the behaviors of the class when you make judgement calls. I bet many of us are already doing this without realizing it. But, in the end, you've got to admit that the rule is pretty bad at doing it's job if there's these unspoken asterisks you have to learn about in order to apply it properly (normally it's taught as "if X is-a Y, use inheritance" without further explanation), plus, this asterisk is basically causing is-a to emulate LSP. Might as well just use LSP from the start. – Akene 15/6, 2022 at 2:32

Maybe already said. But maybe a square and a rectangle is like a boy and a girl. Without thinking this through, maybe they both are polygons so maybe, just maybe this example suggest that our subtypes need to changed. thing like area calls, parameters could be different for each, thus again breaking the rule – Celinacelinda 25/7, 2022 at 2:31

@Jenness I think (width == height) is an invariant not a precondition. What do you think? – Orr 16/10, 2022 at 20:34

@Orr It is a 5 years old comment, I don't even remember. :D Sure, in a square it can be an invariant. I think what matters in the case of LSP, that the square should not throw an exception where the rectangle doesn't, which means that I would rather use composition over inheritance in this case and a different interface, something like square.setSize(s) -> inner.rectangle.setDimensions(s, s). Another option is sort of fit to box by choosing always the smaller side for size: square.setDimensions(w,h) -> s = min(w,h), square.setDimensions(s, s). – Jenness 18/10, 2022 at 6:20

I'm hesitating to downvote this as this answer doesnt't provide any example. The question is: "What is an example of the Liskov Substitution Principle?" And this a counter example. An example would be to replace the type of a variable from a SubType to a SuperType without breaking the function/procedure/code snippet – Tempest 12/2, 2023 at 19:56

561

The Liskov Substitution Principle (LSP, lsp) is a concept in Object Oriented Programming that states:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

At its heart LSP is about interfaces and contracts as well as how to decide when to extend a class vs. use another strategy such as composition to achieve your goal.

The most effective way I have seen to illustrate this point was in Head First OOA&D. They present a scenario where you are a developer on a project to build a framework for strategy games.

They present a class that represents a board that looks like this:

Class Diagram

All of the methods take X and Y coordinates as parameters to locate the tile position in the two-dimensional array of Tiles. This will allow a game developer to manage units in the board during the course of the game.

The book goes on to change the requirements to say that the game frame work must also support 3D game boards to accommodate games that have flight. So a ThreeDBoard class is introduced that extends Board.

At first glance this seems like a good decision. Board provides both the Height and Width properties and ThreeDBoard provides the Z axis.

Where it breaks down is when you look at all the other members inherited from Board. The methods for AddUnit, GetTile, GetUnits and so on, all take both X and Y parameters in the Board class but the ThreeDBoard needs a Z parameter as well.

So you must implement those methods again with a Z parameter. The Z parameter has no context to the Board class and the inherited methods from the Board class lose their meaning. A unit of code attempting to use the ThreeDBoard class as its base class Board would be very out of luck.

Maybe we should find another approach. Instead of extending Board, ThreeDBoard should be composed of Board objects. One Board object per unit of the Z axis.

This allows us to use good object oriented principles like encapsulation and reuse and doesn’t violate LSP.

Boys answered 11/9, 2008 at 15:34 Comment(11)

See also Circle-Ellipse Problem on Wikipedia for a similar but simpler example. – Impolicy 21/10, 2011 at 17:55

Requote from @NotMySelf: "I think the example is simply to demonstrate that inheriting from board does not make sense with in the context of ThreeDBoard and all of the method signatures are meaningless with a Z axis.". – Glandulous 5/6, 2013 at 16:40

Requote from @Chris Ammerman: "Evaluating LSP adherence can be a great tool in determining when composition is the more appropriate mechanism for extending existing functionality, rather than inheritance." – Glandulous 5/6, 2013 at 16:41

So if we add another method to a Child class but all the functionality of Parent still makes sense in the Child class would it be breaking LSP? Since on one hand we modified the interface for using the Child a bit on the other hand if we up cast the Child to be a Parent the code that expects a Parent would work fine. – Landfall 18/6, 2013 at 16:45

This is an anti-Liskov example. Liskov makes us to derive Rectangle from the Square. More-parameters-class from less-parameters-class. And you have nicely shown that it is bad. It is really a good joke to have marked as an answer and to have been upvoted 200 times an anti-liskov answer for liskov question. Is Liskov principle a fallacy really? – Kirima 18/10, 2015 at 8:40

@Glandulous And can you bring an example where inheritance is good, according to the citation in the answer here? – Kirima 18/10, 2015 at 8:42

I've seen inheritance work the wrong way. Here is an example. The base class should be 3DBoard and the derived class Board. The Board still has a Z axis of Max(Z) = Min(Z) = 1 – Hockenberry 5/8, 2017 at 14:52

@Nickolay Kondratyev, yep, doesn't break LSP, you solved it yourself. – Gratify 12/7, 2018 at 13:55

Can we solve the problem without using composition? I think it can be done by changing the signature of GetUnits(int x, int y) to GetUnits(Position pos) and same goes for the other functions. That way, it won't violate LSP. Correct me if I'm wrong. – Arethaarethusa 22/4, 2020 at 20:3

@Hockenberry this brakes the open-closed principle. What if you want a FourDBoard? You would have to make that a base class of ThreeDBoard, their by changing the implementation of ThreeDBoard (you might not even have access to). – Incontrollable 19/7, 2020 at 9:52

Numpy solved this exact problem with the ndarray. A 3-dimensional, 2-dimensional, and 1-dimensional array are all specializations of the generalized n-dimensional array. Mathematicians figured this out centuries ago. Programmers are gradually reinventing algebra. – Standby 22/12, 2020 at 18:57

478

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

Let's do a simple example in Java:

Bad example

public class Bird{
    public void fly(){}
}
public class Duck extends Bird{}

The duck can fly because it is a bird, but what about this:

public class Ostrich extends Bird{}

Ostrich is a bird, but it can't fly, Ostrich class is a subtype of class Bird, but it shouldn't be able to use the fly method, that means we are breaking the LSP principle.

Good example

public class Bird{}
public class FlyingBird extends Bird{
    public void fly(){}
}
public class Duck extends FlyingBird{}
public class Ostrich extends Bird{}

Integer answered 4/7, 2017 at 19:58 Comment(9)

Nice example, but what would you do if the client has Bird bird. You have to cast the object to FlyingBirds to make use of fly, which isn't nice right? – Quiles 20/11, 2017 at 1:5

No. If the client has Bird bird, that means it cannot use fly(). That's it. Passing a Duck does not change this fact. If the client has FlyingBirds bird, then even if it gets passed a Duck it should always work the same way. – Courthouse 18/2, 2018 at 18:56

Wouldn't this also serve as a good example for Interface Segregation? – Degraw 5/3, 2019 at 18:50

How about using Interface 'Flyable' (can't think of a better name). This way we don't commit ourselves into this rigid hierarchy.. Unless we know really need it. – Catechu 28/5, 2019 at 12:32

Vet which cures broken wings will see a Bad example like a better one. Some flightless bird species can fly their own way (chicken is a hybrid here). Also flying ability changes in evolution. A default NULL-able fly method is a good decision, to be overridden later. – Enthusiasm 31/1, 2020 at 18:57

So, the parent class should only include the behaviors that its entire children have or in other words, not limiting its children behaviors. – Yakut 25/2, 2020 at 15:29

What about throwing an exception when calling the ostrich fly method and adding the canFly method to check that the bird can fly or not? – Orlene 29/5, 2022 at 15:15

This in my opinion is the best example to understand. It would be very tempting to have Ostrich extend Bird with a NonSupportedException for Fly(), which would be Anti Liskov – Backcourt 18/4, 2023 at 12:58

It should say FlyingBird to at least be consistent here. (My eye twitches seeing FlyingBirds beeing the only Plural class). – Topmast 6/3 at 7:25

157

LSP concerns invariants.

The classic example is given by the following pseudo-code declaration (implementations omitted):

class Rectangle {
    int getHeight()
    void setHeight(int value) {
        postcondition: width didn’t change
    }
    int getWidth()
    void setWidth(int value) {
        postcondition: height didn’t change
    }
}

class Square extends Rectangle { }

Now we have a problem although the interface matches. The reason is that we have violated invariants stemming from the mathematical definition of squares and rectangles. The way getters and setters work, a Rectangle should satisfy the following invariant:

void invariant(Rectangle r) {
    r.setHeight(200)
    r.setWidth(100)
    assert(r.getHeight() == 200 and r.getWidth() == 100)
}

However, this invariant (as well as the explicit postconditions) must be violated by a correct implementation of Square, therefore it is not a valid substitute of Rectangle.

Allheal answered 12/9, 2008 at 13:45 Comment(36)

And hence the difficulty of using "OO" to model anything we might want to actually model. – Independency 30/11, 2009 at 6:54

@DrPizza: Absolutely. However, two things. Firstly, such relationships can still be modelled in OOP, albeit incompletely or using more complex detours (pick whichever suits your problem). Secondly, there’s no better alternative. Other mappings/modellings have the same or similar problems. ;-) – Allheal 30/11, 2009 at 9:11

@KonradRudolph, It's a good example. What's the right way to declare Square then? – Rixdollar 23/1, 2012 at 20:10

@NickW In some cases (but not in the above) you can simply invert the inheritance chain – logically speaking, a 2D point is-a 3D point, where the third dimension is disregarded (or 0 – all points lie on the same plane in 3D space). But this is of course not really practical. In general, this is one of the cases where inheritance doesn’t really help, and no natural relationship exists between the entities. Model them separately (at least I don’t know of a better way). – Allheal 24/1, 2012 at 9:49

OOP is meant to model behaviours and not data. Your classes violate encapsulation even before violating LSP. – Unison 19/5, 2012 at 21:47

@Unison I agree. It was hard to come up with a concise example though, and this one is the stock LSP example (you’ll find it in several books). But yes, while common, this is far from good OOP. – Allheal 20/5, 2012 at 8:37

The setHeight() and setWidth() methods probably should not be allowed to exist because that makes a class mutable. However, should they exist, one could just throw NotSupportedException() / NotImplementedException() or something similar. – Journalistic 3/7, 2012 at 16:50

@Journalistic In a way, that also breaks the contract since it changes the “signature” (i.e. the possible ways in which the function can exit). Now, some frameworks (ahem .NET …) routinely use this route but I consider it very bad interface design. – Allheal 3/7, 2012 at 18:0

I dont understand how ls LSP violated here. The invariant states that the getheight and getwidth should return the set height and set width which is always true regardless of weather rectangle is square or rectangle. If client sets different height and width, surely he knows the object is a not a square. Similarly, if client knew the object is square, he will set equal heigh and width. Assuming rectangle class had two functions area and perimeter, the functions would work properly whether rectangle is a square or not. Then how is this violating LSP ? – Regimentals 5/6, 2013 at 18:31

@Regimentals “which is always true regardless of weather rectangle is square or rectangle” – false. With a properly coded square this will not always true, both setters need to reset both width and height, otherwise they won’t preserve the (implied) invariants of a square. In other words: you have an inconsistent type system, and you never want that. – Allheal 5/6, 2013 at 21:20

@Regimentals "Assuming rectangle had two functions area and perimeter" would lead to the same problem. SetArea(4); SetPerimeter(10); would make a regular rectangle model a 1x4 rectangle. The calls would make a Square class model first a 2x2, and then either change to a sqrt(10)xsqrt(10) square or throw an InvalidOperationException or something. – Botulinus 7/8, 2016 at 17:41

If there aren't actual invariants, how can you have violated them? How does one know what variants exist to be violated (or conformed)? – Atrice 12/8, 2016 at 18:15

@Atrice You either need to make invariants explicit (aka. assertions, or using the type system) or you need to know the domain you’re working in. We know how rectangles and squares are defined, so we know what invariants they impose. – Allheal 13/8, 2016 at 14:41

I agree - either the constraints or invariants should be explicit, or they should be forced upon you by the system. But, based on your example, there is nothing forcing me to write a square class with the "implied" invariant you mentioned. I suppose I'd suggest updating your answer to remove "implied" when discussing the invariants, they are actual constraints that give rise to the problem. – Atrice 13/8, 2016 at 21:35

LSP should not know what the derived object does, just that derived objects honour the base class contract. For example Square can have SetDepth(int d) => throw exception. But I wonder...is a rectangle a special type of square that doesn't demand H=W? Alternatively..Quadrilateral ⇒ Trapezoid ⇒ Parallelogram. – Hockenberry 5/8, 2017 at 15:0

Alternatively..Quadrilateral ⇒ Trapezoid ⇒ Parallelogram. Rectangle and Square will ultimately derive. from Parallelogram, although there would be Parallelogram ⇒ Rhombus ⇒ Square. Getting your derivations right is like designing database tables. Get it wrong at the start and you are heading for a screw-up – Hockenberry 5/8, 2017 at 15:14

Would it make more sense for a Rectangle to inherit from a type of Square, or to have Square and Rectangle just be sibling classes? – Apocarp 8/5, 2018 at 23:54

@Apocarp You’d avoid this particular issue but the relationship doesn’t really make sense: inheritance models “is-a” relationships and “every rectangle is-a square” is wrong (and, as a consequence, you would run into other issues where you can’t simply replace one for the other). It’s correct the other way round (“every square is-a rectangle”), which is why it’s so tempting to write code that violates LSP. – Allheal 9/5, 2018 at 10:1

@KonradRudolph So then would it be better to keep them as sibling classes that inherit from Shape or Parallelogram or something? – Apocarp 9/5, 2018 at 16:35

@Apocarp Yep; the longer I’ve been working in this field, the more I tend to use inheritance for interfaces and abstract base classes only, and composition for the rest. It’s sometimes a bit more work (typing wise) but it avoids a whole bunch of problems, and is widely echoed advice by other experienced programmers. – Allheal 9/5, 2018 at 16:37

@KonradRudolph Wow, I had no idea, though, on my last project, I did experience the problems of using too much inheritance. I realized I wanted to give some derived classes the properties of other derived classes, and there was no way to do that. Do you think only abstract classes should have children, for the most part? – Apocarp 9/5, 2018 at 16:47

@Apocarp For the most part, yes. It’s famously one of the rules of the influential Effective C++ books, and a more general rule, Composition over Inheritance, has its own Wikipedia page. – Allheal 9/5, 2018 at 17:22

@KonradRudolph Wow, thanks, I'll check this out. Is that book still worth a read for C# development, to learn structures and design patterns? – Apocarp 9/5, 2018 at 20:59

@Apocarp Probably not, unfortunately; it’s very specific to C++. Bill Wagner’s Effective C# follows a similar pattern though. – Allheal 9/5, 2018 at 21:54

@Rixdollar For modeling the Square from a Rectangle, if a polymorphic approach is not a must, I would advocate for a SquareDecorator which takes the Rectangle object. What you or anybody else think of that? – Historical 11/1, 2019 at 16:35

@ReuelRibeiro This goes into the direction of over-engineering; most of the time it would be better to simply provide orthogonal classes that might both inherit from a Shape. That said, your approach is certainly the correct solution in many real-life use-cases. – Allheal 11/1, 2019 at 17:29

I'm not convinced this is a good example of violating LSP. I understand it's somewhat the canonical example used, but the assertion used to prove the violation isn't open and shut. Yes, when you read the code it seems obvious. I just set the width and the height, why is the height not what I set it to? But setting the width and height are two separate operations, and after-all, the reason we have methods to set properties, rather than exposing the properties themselves, is so we can maintain our invariants, which may result in side-effects. – Banksia 12/10, 2020 at 21:51

In essence, I'm saying that while this may be a violation, it's far from obvious that it is, and thus shouldn't be used as an example for people trying to learn this concept. – Banksia 12/10, 2020 at 21:52

@Banksia I see where you’re coming from but your comment ignores the specific context of the example. Namely, we’re not just calling any old setter on any old object type. We’re specifically assigning width and height of a rectangle. And this comes with implicit expectations (an implicit contract). The (implicit) expectation is that modifying the width does not modify the height, and vice-versa. There are reasons to change this contract (after all, that’s what a square does!). But in general these are the natural expectations. The substitution (with a square) violates that generality. – Allheal 12/10, 2020 at 22:37

@KonradRudolph I was not ignoring the fact that the assertion was in the context of a Rectangle, and I never said it wasn't a violation of LSP. It is not obvious at all that there is an implicit contract that says changing the width of the Rectangle cannot change the height, and vice-versa. Since changing the width is a separate operation from changing the height, I don't see an implicit contract that says a square can't enforce its invariants when the width or height is changed in isolation, as a rectangle. – Banksia 13/10, 2020 at 1:34

@KonradRudolph Your example assertion forced width and height to be set at the same time by combining two separate operations, but the actual contract of a rectangle has these operations as separate, which is what makes this whole example an exercise of interpretation, rather than a concrete violation of LSP – Banksia 13/10, 2020 at 1:36

@Banksia “I don't see an implicit contract” — You don’t see it because it’s implicit. You could make it explicit by adding assertions to the Rectangle base class setters that ensure the other value isn’t modified. But the fact that squares have a different implicit contract is precisely why this is an LSP violation: both are valid in isolation, but a square is not a valid subtype of a rectangle, because their implicit contracts aren’t compatible. – Allheal 13/10, 2020 at 7:48

@Banksia I’ve added explicit postconditions to my declaration of the Rectangle class. But fair warning: I might end up removing them again because they’re artificial and at any rate already captured by the invariant example method. And furthermore LSP by its original definition also concerns implicit invariants, not just explicit ones. The original example without the postconditions was very much in line with the original, formal definition of LSP. – Allheal 13/10, 2020 at 7:52

@KonradRudolph The problem is that "implicit" invariants are debatable. They aren't necessarily set in stone. Your interpretation of what constitutes an implicit invariant in this case is very much opinionated and based on the context of the application. – Banksia 19/10, 2020 at 18:1

@KonradRudolph I can argue that since setHeight() and setWidth() are independent operations, that each in and of itself is not a violation of any invariant. It's only when you try to force the independent operations to be one operation that your view of what you think is an implicit invariant can be seen. So at best, this is a weak case for a violation of LSP – Banksia 19/10, 2020 at 18:13

@Banksia “It's only when you try to force the independent operations to be one operation” — No, we’re not forcing them to be one operation — they’re clearly not one operation. What we’re forcing is an invariant, i.e. assertions about the state of the object. And, again, that’s the whole point of LSP: invariants. It’s about invariants, not about operations. – Allheal 19/10, 2020 at 19:28

Robert Martin has an excellent paper on the Liskov Substitution Principle. It discusses subtle and not-so-subtle ways in which the principle may be violated.

Some relevant parts of the paper (note that the second example is heavily condensed):

A Simple Example of a Violation of LSP

One of the most glaring violations of this principle is the use of C++ Run-Time Type Information (RTTI) to select a function based upon the type of an object. i.e.:
void DrawShape(const Shape& s)
{
  if (typeid(s) == typeid(Square))
    DrawSquare(static_cast<Square&>(s)); 
  else if (typeid(s) == typeid(Circle))
    DrawCircle(static_cast<Circle&>(s));
}
Clearly the DrawShape function is badly formed. It must know about every possible derivative of the Shape class, and it must be changed whenever new derivatives of Shape are created. Indeed, many view the structure of this function as anathema to Object Oriented Design.

Square and Rectangle, a More Subtle Violation.

However, there are other, far more subtle, ways of violating the LSP. Consider an application which uses the Rectangle class as described below:
class Rectangle
{
  public:
    void SetWidth(double w) {itsWidth=w;}
    void SetHeight(double h) {itsHeight=w;}
    double GetHeight() const {return itsHeight;}
    double GetWidth() const {return itsWidth;}
  private:
    double itsWidth;
    double itsHeight;
};
[...] Imagine that one day the users demand the ability to manipulate squares in addition to rectangles. [...]

Clearly, a square is a rectangle for all normal intents and purposes. Since the ISA relationship holds, it is logical to model the Square class as being derived from Rectangle. [...]

Square will inherit the SetWidth and SetHeight functions. These functions are utterly inappropriate for a Square, since the width and height of a square are identical. This should be a significant clue that there is a problem with the design. However, there is a way to sidestep the problem. We could override SetWidth and SetHeight [...]

But consider the following function:
void f(Rectangle& r)
{
  r.SetWidth(32); // calls Rectangle::SetWidth
}
If we pass a reference to a Square object into this function, the Square object will be corrupted because the height won’t be changed. This is a clear violation of LSP. The function does not work for derivatives of its arguments.

[...]

Skater answered 12/9, 2008 at 13:34 Comment(3)

Way late, but I thought this was an interesting quote in that paper:

Now the rule for the preconditions and postconditions for derivatives, as stated by Meyer is: ...when redefining a routine [in a derivative], you may only replace its precondition by a weaker one, and its postcondition by a stronger one.

If a child-class pre-condition is stronger than a parent class pre-condition, you couldn't substitute a child for a parent without violating the pre-condition. Hence LSP. – Christcross 11/2, 2015 at 15:31

I have implemented diagram editor in past. Robust implementation may be setHeight(x) { this.height = x; this.width = x } and similar for setWidth(). It will work well for horizontal and vertical resize controls, but will require some workarounds for corner resize controls. – Wench 31/7, 2022 at 5:54

Actually Rect, from perspective of drawing application, is not something having width and height. Instead it is something having (x1,y1) and (x2,y2). Even Line and Circle may be represented as box-outlined shape. Additionally, for drawing app it is important to know how we define anchor (x,y), which may be calculated differently and transparently for different kinds of shapes. – Wench 31/7, 2022 at 6:10

There is a checklist to determine whether or not you are violating Liskov.

If you violate one of the following items -> you violate Liskov.
If you don't violate any -> can't conclude anything.

Check list:

No new exceptions should be thrown in derived class: If your base class threw ArgumentNullException then your sub classes were only allowed to throw exceptions of type ArgumentNullException or any exceptions derived from ArgumentNullException. Throwing IndexOutOfRangeException is a violation of Liskov.
Pre-conditions cannot be strengthened: Assume your base class works with a member int. Now your sub-type requires that int to be positive. This is strengthened pre-conditions, and now any code that worked perfectly fine before with negative ints is broken.
Post-conditions cannot be weakened: Assume your base class required all connections to the database should be closed before the method returned. In your sub-class you overrode that method and left the connection open for further reuse. You have weakened the post-conditions of that method.
Invariants must be preserved: The most difficult and painful constraint to fulfill. Invariants are sometimes hidden in the base class and the only way to reveal them is to read the code of the base class. Basically you have to be sure when you override a method anything unchangeable must remain unchanged after your overridden method is executed. The best thing I can think of is to enforce these invariant constraints in the base class but that would not be easy.

History Constraint: When overriding a method you are not allowed to modify an unmodifiable property in the base class. Take a look at these code and you can see Name is defined to be unmodifiable (private set) but SubType introduces new method that allows modifying it (through reflection):

 public class SuperType
 {
     public string Name { get; private set; }
     public SuperType(string name, int age)
     {
         Name = name;
         Age = age;
     }
 }
 public class SubType : SuperType
 {
     public void ChangeName(string newName)
     {
         var propertyType = base.GetType().GetProperty("Name").SetValue(this, newName);
     }
 }

There are 2 others items: Contravariance of method arguments and Covariance of return types. But it is not possible in C# (I'm a C# developer) so I don't care about them.

Lipfert answered 13/8, 2016 at 14:26 Comment(1)

I'm a C# developer also and I will tell your last statement isn't true as of Visual Studio 2010, with the .Net 4.0 framework. Covariance of return types allows for a more derived return type than what was defined by the interface. Example: Example: IEnumerable<T> (T is covariant) IEnumerator<T> (T is covariant) IQueryable<T> (T is covariant) IGrouping<TKey, TElement> (TKey and TElement are covariant) IComparer<T> (T is contravariant) IEqualityComparer<T> (T is contravariant) IComparable<T> (T is contravariant) msdn.microsoft.com/en-us/library/dd233059(v=vs.100).aspx – Shawnna 5/9, 2017 at 3:48

I see rectangles and squares in every answer, and how to violate the LSP.

I'd like to show how the LSP can be conformed to with a real-world example :

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return $result; 
    }
}

This design conforms to the LSP because the behaviour remains unchanged regardless of the implementation we choose to use.

And yes, you can violate LSP in this configuration doing one simple change like so :

<?php

interface Database 
{
    public function selectQuery(string $sql): array;
}

class SQLiteDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // sqlite specific code

        return $result;
    }
}

class MySQLDatabase implements Database
{
    public function selectQuery(string $sql): array
    {
        // mysql specific code

        return ['result' => $result]; // This violates LSP !
    }
}

Now the subtypes cannot be used the same way since they don't produce the same result anymore.

Courthouse answered 18/2, 2018 at 19:7 Comment(3)

The example does not violate LSP only as long as we constrain the semantics of Database::selectQuery to support just the subset of SQL supported by all DB engines. That's hardly practical... That said, the example is still easier to grasp than most others used here. – Nowak 25/2, 2018 at 13:2

I found this answer the easiest to grasp out of the rest. – Ultra 11/2, 2019 at 17:14

is it practical to apply LSP on databases? i see that most, if not all the, of db operations will need to be wrapped, and is vulnerable to mistakes. Though the good side is the API stays the same even if it's SQL vs NoSQL. – Adaurd 23/8, 2020 at 15:59

LSP is necessary where some code thinks it is calling the methods of a type T, and may unknowingly call the methods of a type S, where S extends T (i.e. S inherits, derives from, or is a subtype of, the supertype T).

For example, this occurs where a function with an input parameter of type T, is called (i.e. invoked) with an argument value of type S. Or, where an identifier of type T, is assigned a value of type S.

val id : T = new S() // id thinks it's a T, but is a S

LSP requires the expectations (i.e. invariants) for methods of type T (e.g. Rectangle), not be violated when the methods of type S (e.g. Square) are called instead.

val rect : Rectangle = new Square(5) // thinks it's a Rectangle, but is a Square
val rect2 : Rectangle = rect.setWidth(10) // height is 10, LSP violation

Even a type with immutable fields still has invariants, e.g. the immutable Rectangle setters expect dimensions to be independently modified, but the immutable Square setters violate this expectation.

class Rectangle( val width : Int, val height : Int )
{
   def setWidth( w : Int ) = new Rectangle(w, height)
   def setHeight( h : Int ) = new Rectangle(width, h)
}

class Square( val side : Int ) extends Rectangle(side, side)
{
   override def setWidth( s : Int ) = new Square(s)
   override def setHeight( s : Int ) = new Square(s)
}

LSP requires that each method of the subtype S must have contravariant input parameter(s) and a covariant output.

Contravariant means the variance is contrary to the direction of the inheritance, i.e. the type Si, of each input parameter of each method of the subtype S, must be the same or a supertype of the type Ti of the corresponding input parameter of the corresponding method of the supertype T.

Covariance means the variance is in the same direction of the inheritance, i.e. the type So, of the output of each method of the subtype S, must be the same or a subtype of the type To of the corresponding output of the corresponding method of the supertype T.

This is because if the caller thinks it has a type T, thinks it is calling a method of T, then it supplies argument(s) of type Ti and assigns the output to the type To. When it is actually calling the corresponding method of S, then each Ti input argument is assigned to a Si input parameter, and the So output is assigned to the type To. Thus if Si were not contravariant w.r.t. to Ti, then a subtype Xi—which would not be a subtype of Si—could be assigned to Ti.

Additionally, for languages (e.g. Scala or Ceylon) which have definition-site variance annotations on type polymorphism parameters (i.e. generics), the co- or contra- direction of the variance annotation for each type parameter of the type T must be opposite or same direction respectively to every input parameter or output (of every method of T) that has the type of the type parameter.

Additionally, for each input parameter or output that has a function type, the variance direction required is reversed. This rule is applied recursively.

Subtyping is appropriate where the invariants can be enumerated.

There is much ongoing research on how to model invariants, so that they are enforced by the compiler.

Typestate (see page 3) declares and enforces state invariants orthogonal to type. Alternatively, invariants can be enforced by converting assertions to types. For example, to assert that a file is open before closing it, then File.open() could return an OpenFile type, which contains a close() method that is not available in File. A tic-tac-toe API can be another example of employing typing to enforce invariants at compile-time. The type system may even be Turing-complete, e.g. Scala. Dependently-typed languages and theorem provers formalize the models of higher-order typing.

Because of the need for semantics to abstract over extension, I expect that employing typing to model invariants, i.e. unified higher-order denotational semantics, is superior to the Typestate. ‘Extension’ means the unbounded, permuted composition of uncoordinated, modular development. Because it seems to me to be the antithesis of unification and thus degrees-of-freedom, to have two mutually-dependent models (e.g. types and Typestate) for expressing the shared semantics, which can't be unified with each other for extensible composition. For example, Expression Problem-like extension was unified in the subtyping, function overloading, and parametric typing domains.

My theoretical position is that for knowledge to exist (see section “Centralization is blind and unfit”), there will never be a general model that can enforce 100% coverage of all possible invariants in a Turing-complete computer language. For knowledge to exist, unexpected possibilities much exist, i.e. disorder and entropy must always be increasing. This is the entropic force. To prove all possible computations of a potential extension, is to compute a priori all possible extension.

This is why the Halting Theorem exists, i.e. it is undecidable whether every possible program in a Turing-complete programming language terminates. It can be proven that some specific program terminates (one which all possibilities have been defined and computed). But it is impossible to prove that all possible extension of that program terminates, unless the possibilities for extension of that program is not Turing complete (e.g. via dependent-typing). Since the fundamental requirement for Turing-completeness is unbounded recursion, it is intuitive to understand how Gödel's incompleteness theorems and Russell's paradox apply to extension.

An interpretation of these theorems incorporates them in a generalized conceptual understanding of the entropic force:

Gödel's incompleteness theorems: any formal theory, in which all arithmetic truths can be proved, is inconsistent.
Russell's paradox: every membership rule for a set that can contain a set, either enumerates the specific type of each member or contains itself. Thus sets either cannot be extended or they are unbounded recursion. For example, the set of everything that is not a teapot, includes itself, which includes itself, which includes itself, etc…. Thus a rule is inconsistent if it (may contain a set and) does not enumerate the specific types (i.e. allows all unspecified types) and does not allow unbounded extension. This is the set of sets that are not members of themselves. This inability to be both consistent and completely enumerated over all possible extension, is Gödel's incompleteness theorems.
Liskov Substition Principle: generally it is an undecidable problem whether any set is the subset of another, i.e. inheritance is generally undecidable.
Linsky Referencing: it is undecidable what the computation of something is, when it is described or perceived, i.e. perception (reality) has no absolute point of reference.
Coase's theorem: there is no external reference point, thus any barrier to unbounded external possibilities will fail.
Second law of thermodynamics: the entire universe (a closed system, i.e. everything) trends to maximum disorder, i.e. maximum independent possibilities.

Popsicle answered 26/11, 2011 at 16:35 Comment(6)

@Shelyby: You have mixed too many things. Things are not as confusing as you state them. Much of your theoretical assertions stand on flimsy grounds, like 'For knowledge to exist, unexpected possibilities much exist, .........' AND 'generally it is an undecidable problem whether any set is the subset of another, i.e. inheritance is generally undecidable' . You can start up a separate blog for each of these points. Anyways, your assertions and assumptions are highly questionable. One must not use things which one is not aware of! – Strick 27/12, 2013 at 5:3

@Strick I have a blog that explains these matters in more depth. My TOE model of infinite spacetime is unbounded frequencies. It is not confusing to me that a recursive inductive function has a known start value with an infinite end bound, or a coinductive function has an unknown end value and a known start bound. Relativity is the problem once recursion is introduced. This is why Turing complete is equivalent to unbounded recursion. – Popsicle 16/3, 2014 at 8:38

@ShelbyMooreIII You are going in too many directions. This is not an answer. – Aftersensation 9/12, 2016 at 14:48

@Aftersensation it is an answer. Don't you see it in the Answer section. Yours is a comment because it is in the comment section. – Popsicle 23/12, 2016 at 12:54

@Strick as for your allegations of "flimsy", I've blogged and written since my reply to you in 2014. – Popsicle 23/12, 2016 at 13:1

Like your mixing with scala world! – Sapphira 28/6, 2017 at 18:38

Long story short, let's leave rectangles rectangles and squares squares, practical example when extending a parent class, you have to either PRESERVE the exact parent API or to EXTEND IT.

Let's say you have a base ItemsRepository.

class ItemsRepository
{
    /**
    * @return int Returns number of deleted rows
    */
    public function delete()
    {
        // perform a delete query
        $numberOfDeletedRows = 10;

        return $numberOfDeletedRows;
    }
}

And a sub class extending it:

class BadlyExtendedItemsRepository extends ItemsRepository
{
    /**
     * @return void Was suppose to return an INT like parent, but did not, breaks LSP
     */
    public function delete()
    {
        // perform a delete query
        $numberOfDeletedRows = 10;

        // we broke the behaviour of the parent class
        return;
    }
}

Then you could have a Client working with the Base ItemsRepository API and relying on it.

/**
 * Class ItemsService is a client for public ItemsRepository "API" (the public delete method).
 *
 * Technically, I am able to pass into a constructor a sub-class of the ItemsRepository
 * but if the sub-class won't abide the base class API, the client will get broken.
 */
class ItemsService
{
    /**
     * @var ItemsRepository
     */
    private $itemsRepository;

    /**
     * @param ItemsRepository $itemsRepository
     */
    public function __construct(ItemsRepository $itemsRepository)
    {
        $this->itemsRepository = $itemsRepository;
    }

    /**
     * !!! Notice how this is suppose to return an int. My clients expect it based on the
     * ItemsRepository API in the constructor !!!
     *
     * @return int
     */
    public function delete()
    {
        return $this->itemsRepository->delete();
    }
}

The LSP is broken when substituting parent class with a sub class breaks the API's contract.

class ItemsController
{
    /**
     * Valid delete action when using the base class.
     */
    public function validDeleteAction()
    {
        $itemsService = new ItemsService(new ItemsRepository());
        $numberOfDeletedItems = $itemsService->delete();

        // $numberOfDeletedItems is an INT :)
    }

    /**
     * Invalid delete action when using a subclass.
     */
    public function brokenDeleteAction()
    {
        $itemsService = new ItemsService(new BadlyExtendedItemsRepository());
        $numberOfDeletedItems = $itemsService->delete();

        // $numberOfDeletedItems is a NULL :(
    }
}

You can learn more about writing maintainable software in my course: https://www.udemy.com/enterprise-php/

Astor answered 28/10, 2017 at 23:10 Comment(2)

This is a much better example. Thank you! – Tartarean 14/2, 2021 at 17:39

Is this code in PHP? I am not sure if we can implement the same in all the languages, for e.g. in C# we can't have a function return int in base class and overridden method return void from the derived class – Vierra 16/3 at 0:3

Let’s illustrate in Java:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }

   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

class Car extends TransportationDevice
{
   @Override
   void startEngine() { ... }
}

There is no problem here, right? A car is definitely a transportation device, and here we can see that it overrides the startEngine() method of its superclass.

Let’s add another transportation device:

class Bicycle extends TransportationDevice
{
   @Override
   void startEngine() /*problem!*/
}

Everything isn’t going as planned now! Yes, a bicycle is a transportation device, however, it does not have an engine and hence, the method startEngine() cannot be implemented.

These are the kinds of problems that violation of Liskov Substitution Principle leads to, and they can most usually be recognized by a method that does nothing, or even can’t be implemented.

The solution to these problems is a correct inheritance hierarchy, and in our case we would solve the problem by differentiating classes of transportation devices with and without engines. Even though a bicycle is a transportation device, it doesn’t have an engine. In this example our definition of transportation device is wrong. It should not have an engine.

We can refactor our TransportationDevice class as follows:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }
}

Now we can extend TransportationDevice for non-motorized devices.

class DevicesWithoutEngines extends TransportationDevice
{  
   void startMoving() { ... }
}

And extend TransportationDevice for motorized devices. Here is is more appropriate to add the Engine object.

class DevicesWithEngines extends TransportationDevice
{  
   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

Thus our Car class becomes more specialized, while adhering to the Liskov Substitution Principle.

class Car extends DevicesWithEngines
{
   @Override
   void startEngine() { ... }
}

And our Bicycle class is also in compliance with the Liskov Substitution Principle.

class Bicycle extends DevicesWithoutEngines
{
   @Override
   void startMoving() { ... }
}

Spatz answered 10/2, 2019 at 10:56 Comment(1)

Your example is more about Interface segregation principle. – Heres 11/12, 2022 at 20:36

The LSP is a rule about the contract of the clases: if a base class satisfies a contract, then by the LSP derived classes must also satisfy that contract.

In Pseudo-python

class Base:
   def Foo(self, arg): 
       # *... do stuff*

class Derived(Base):
   def Foo(self, arg):
       # *... do stuff*

satisfies LSP if every time you call Foo on a Derived object, it gives exactly the same results as calling Foo on a Base object, as long as arg is the same.

Orel answered 8/11, 2008 at 17:53 Comment(9)

But ... if you always get the same behavior, then what is the point of having the derived class? – Journalistic 3/7, 2012 at 17:14

You missed a point: it's the same observed behavior. You might, for example replace something with O(n) performance with something functionally equivalent, but with O(lg n) performance. Or you might replace something that accesses data implemented with MySQL and replace it with an in-memory database. – Orel 4/7, 2012 at 18:6

@Charlie Martin, coding to an interface rather than an implementation - I dig that. This is not unique to OOP; functional languages such as Clojure promote that as well. Even in terms of Java or C#, I think that using an interface rather than using an abstract class plus class hierarchies would be natural for the examples that you provide. Python is not strongly typed and does not really have interfaces, at least not explicitly. My difficulty is that I have been doing OOP for several years without adhering to SOLID. Now that I came across it, it seems limiting and almost self-contradicting. – Pigfish 6/7, 2012 at 18:9

Well, you need to go back and check out Barbara's original paper. reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.ps It's not really stated in terms of interfaces, and it is a logical relation that holds (or doesn't) in any programming language that has some form of inheritance. – Orel 7/7, 2012 at 19:22

@HamishGrubijan I don't know who told you that Python is not strongly typed, but they were lying to you (and if you don't believe me, fire up a Python interpreter and try 2 + "2"). Perhaps you confuse "strongly typed" with "statically typed"? – Sydney 20/1, 2013 at 6:19

@Sydney Hamish is not wrong. "Strongly typed" isn't a well defined term; sometimes it's used to mean "has some kind of static type-checking" (Hamish's meaning), sometimes to mean "doesn't perform type coercion" (your meaning, and as usual only with regard to the specific case of 'string-to-number type coercion' - I've never seen anyone argue that C is weakly typed because you can multiply ints by floats, or that Python is because you can concatenate u'hello' with 'world'), and sometimes to mean one of many other things. en.wikipedia.org/wiki/Strong_and_weak_typing – Jubilant 27/12, 2013 at 10:57

Well from the point of view of Liskov, those are different, because they always work. If a language supports 2 + '2', it still won't support 2 + 'two'. – Sydney 27/12, 2013 at 17:13

Oddly, @MarkAmery, the wiki article you link supports my use of 'strongly typed'. Just because people have been using it wrongly doesn't make the definition wrong. "In 1974, Liskov and Zilles described a strong-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function." – Orel 27/12, 2013 at 18:11

@CharlieMartin, if I understand your answer correctly, then LSP is the ability to replace any instance of a parent class with an instance of one of its child classes without negative side effects, correct? – Inessive 26/10, 2018 at 22:11

I guess everyone kind of covered what LSP is technically: You basically want to be able to abstract away from subtype details and use supertypes safely.

So Liskov has 3 underlying rules:

Signature Rule : There should be a valid implementation of every operation of the supertype in the subtype syntactically. Something a compiler will be able to check for you. There is a little rule about throwing fewer exceptions and being at least as accessible as the supertype methods.
Methods Rule: The implementation of those operations is semantically sound.
- Weaker Preconditions : The subtype functions should take at least what the supertype took as input, if not more.
- Stronger Postconditions: They should produce a subset of the output the supertype methods produced.
Properties Rule : This goes beyond individual function calls.
- Invariants : Things that are always true must remain true. Eg. a Set's size is never negative.
- Evolutionary Properties : Usually something to do with immutability or the kind of states the object can be in. Or maybe the object only grows and never shrinks so the subtype methods shouldn't make it.

All these properties need to be preserved and the extra subtype functionality shouldn't violate supertype properties.

If these three things are taken care of , you have abstracted away from the underlying stuff and you are writing loosely coupled code.

Source: Program Development in Java - Barbara Liskov

Book answered 18/12, 2016 at 16:54 Comment(0)

An important example of the use of LSP is in software testing.

If I have a class A that is an LSP-compliant subclass of B, then I can reuse the test suite of B to test A.

To fully test subclass A, I probably need to add a few more test cases, but at the minimum I can reuse all of superclass B's test cases.

A way to realize is this by building what McGregor calls a "Parallel hierarchy for testing": My ATest class will inherit from BTest. Some form of injection is then needed to ensure the test case works with objects of type A rather than of type B (a simple template method pattern will do).

Note that reusing the super-test suite for all subclass implementations is in fact a way to test that these subclass implementations are LSP-compliant. Thus, one can also argue that one should run the superclass test suite in the context of any subclass.

See also the answer to the Stackoverflow question "Can I implement a series of reusable tests to test an interface's implementation?"

Usia answered 25/3, 2013 at 21:26 Comment(0)

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

When I first read about LSP, I assumed that this was meant in a very strict sense, essentially equating it to interface implementation and type-safe casting. Which would mean that LSP is either ensured or not by the language itself. For example, in this strict sense, ThreeDBoard is certainly substitutable for Board, as far as the compiler is concerned.

After reading up more on the concept though I found that LSP is generally interpreted more broadly than that.

In short, what it means for client code to "know" that the object behind the pointer is of a derived type rather than the pointer type is not restricted to type-safety. Adherence to LSP is also testable through probing the objects actual behavior. That is, examining the impact of an object's state and method arguments on the results of the method calls, or the types of exceptions thrown from the object.

Going back to the example again, in theory the Board methods can be made to work just fine on ThreeDBoard. In practice however, it will be very difficult to prevent differences in behavior that client may not handle properly, without hobbling the functionality that ThreeDBoard is intended to add.

With this knowledge in hand, evaluating LSP adherence can be a great tool in determining when composition is the more appropriate mechanism for extending existing functionality, rather than inheritance.

Shipshape answered 11/9, 2008 at 16:4 Comment(0)

The Liskov Substitution Principle

The overridden method shouldn’t remain empty
The overridden method shouldn’t throw an error
Base class or interface behavior should not go for modification (rework) as because of derived class behaviors.

Digastric answered 19/8, 2019 at 11:55 Comment(0)

The LSP in simple terms states that objects of the same superclass should be able to be swapped with each other without breaking anything.

For example, if we have a Cat and a Dog class derived from an Animal class, any functions using the Animal class should be able to use Cat or Dog and behave normally.

Mucilage answered 24/1, 2020 at 12:19 Comment(0)

In a very simple sentence, we can say:

The child class must not violate its base class characteristics. It must be capable with it. We can say it's same as subtyping.

Fungistat answered 16/8, 2017 at 8:40 Comment(0)

This formulation of the LSP is way too strong:

If for each object o1 of type S there is an object o2 of type T such that for all programs P deﬁned in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

Which basically means that S is another, completely encapsulated implementation of the exact same thing as T. And I could be bold and decide that performance is part of the behavior of P...

So, basically, any use of late-binding violates the LSP. It's the whole point of OO to to obtain a different behavior when we substitute an object of one kind for one of another kind!

The formulation cited by wikipedia is better since the property depends on the context and does not necessarily include the whole behavior of the program.

Colossae answered 3/4, 2009 at 0:11 Comment(3)

Erm, that formulation is Barbara Liskov's own. Barbara Liskov, “Data Abstraction and Hierarchy,” SIGPLAN Notices, 23,5 (May, 1988). It is not "way too strong", it is "exactly right", and it does not have the implication you think it has. It is strong, but has just the right amount of strength. – Independency 30/11, 2009 at 7:8

Then, there are very few subtypes in the real life :) – Colossae 8/12, 2009 at 22:26

"Behavior is unchanged" does not mean that a subtype will give you the exact same concrete result value(s). It means that the subtype's behavior matches what is expected in the base type. Example: base type Shape could have a draw() method and stipulate that this method should render the shape. Two subtypes of Shape (e.g. Square and Circle) would both implement the draw() method and the results would look different. But as long as the behavior (rendering the shape) matched the specified behavior of Shape, then Square and Circle would be subtypes of Shape in accordance with the LSP. – Invaluable 11/10, 2012 at 19:38

Liskov's Substitution Principle(LSP)

All the time we design a program module and we create some class hierarchies. Then we extend some classes creating some derived classes.

We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise, the new classes can produce undesired effects when they are used in existing program modules.

Liskov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

Example:

Below is the classic example for which the Liskov's Substitution Principle is violated. In the example, 2 classes are used: Rectangle and Square. Let's assume that the Rectangle object is used somewhere in the application. We extend the application and add the Square class. The square class is returned by a factory pattern, based on some conditions and we don't know the exact what type of object will be returned. But we know it's a Rectangle. We get the rectangle object, set the width to 5 and height to 10 and get the area. For a rectangle with width 5 and height 10, the area should be 50. Instead, the result will be 100

    // Violation of Likov's Substitution Principle
class Rectangle {
    protected int m_width;
    protected int m_height;

    public void setWidth(int width) {
        m_width = width;
    }

    public void setHeight(int height) {
        m_height = height;
    }

    public int getWidth() {
        return m_width;
    }

    public int getHeight() {
        return m_height;
    }

    public int getArea() {
        return m_width * m_height;
    }
}

class Square extends Rectangle {
    public void setWidth(int width) {
        m_width = width;
        m_height = width;
    }

    public void setHeight(int height) {
        m_width = height;
        m_height = height;
    }

}

class LspTest {
    private static Rectangle getNewRectangle() {
        // it can be an object returned by some factory ...
        return new Square();
    }

    public static void main(String args[]) {
        Rectangle r = LspTest.getNewRectangle();

        r.setWidth(5);
        r.setHeight(10);
        // user knows that r it's a rectangle.
        // It assumes that he's able to set the width and height as for the base
        // class

        System.out.println(r.getArea());
        // now he's surprised to see that the area is 100 instead of 50.
    }
}

Conclusion:

This principle is just an extension of the Open Close Principle and it means that we must make sure that new derived classes are extending the base classes without changing their behavior.

Violation Example:

public class Plane{

  public void startEngine(){}      

}        
public class FighterJet extends Plane{}
    
public class PaperPlane extends Plane{}

In the given example FighterPlane and PaperPlane classes both extending the Plane class which contain startEngine() method. So it's clear that FighterPlane can start engine but PaperPlane can’t so it’s breaking LSP.

PaperPlane class although extending Plane class and should be substitutable in place of it but is not an eligible entity that Plane’s instance could be replaced by, because a paper plane can’t start the engine as it doesn’t have one. So the good example would be,

Respected Example:

public class Plane{ 
} 
public class RealPlane{

  public void startEngine(){} 

}
public class FighterJet extends RealPlane{} 
public class PaperPlane extends Plane{}

Padgett answered 22/11, 2020 at 5:9 Comment(1)

In essence, another way to word it is: All of the methods residing in a super class, need to appropriately apply to all of its sub classes. However this would only be one criteria of the substitution principle. – Perse 15/8, 2021 at 14:17

The big picture :

What is Liskov Substitution Principle about ? It's about what is (and what is not) a subtype of a given type.
Why is it so important ? Because there is a difference between a subtype and a subclass.

Example

Unlike the other answers, I won't start with a Liskov Substitution Principle (LSP) violation, but with a LSP compliance. I use Java but it would be almost the same in every OOP language.

`Circle` and `ColoredCircle`

Geometrical examples seem pretty popular here.

class Circle {
    private int radius;

    public Circle(int radius) {
        if (radius < 0) {
            throw new RuntimeException("Radius should be >= 0");
        }
        this.radius = radius;
    }

    public int getRadius() {
        return this.radius;
    }
}

The radius is not allowed to be negative. Here's a suclass:

class ColoredCircle extends Circle {
    private Color color; // defined elsewhere

    public ColoredCircle(int radius, Color color) {
        super(radius);
        this.color = color;
    }

    public Color getColor() {
        return this.color;
    }
}

This subclass is a subtype of Circle, according to the LSP.

The LSP states that:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T. (Barbara Liskov, "Data Abstraction and Hierarchy", SIGPLAN Notices, 23,5 (May, 1988))

Here, for each ColoredCircle instance o1, consider the Circle instance having the same radius o2. For every program using Circle objects, if you replace o2 by o1, the behavior of any program using Circle will remain the same after the substitution. (Note that this is theoretical : you will exhaust the memory faster using ColoredCircle instances than using Circle instances, but that's not relevant here.)

How do we find the o2 depending on o1 ? We just strip the color attribute and keep the radius attribute. I call the transformation o1 -> o2 a projection from the CircleColor space on the Circle space.

Counter Example

Let's create another example to illustrate the violation of the LSP.

`Circle` and `Square`

Imagine this subclass of the previous Circle class:

class Square extends Circle {
    private int sideSize;

    public Square(int sideSize) {
        super(0);
        this.sideSize = sideSize;
    }

    @Override
    public int getRadius() {
        return -1; // I'm a square, I don't care
    }

    public int getSideSize() {
        return this.sideSize;
    }
}

The violation of the LSP

Now, look at this program :

public class Liskov {
    public static void program(Circle c) {
        System.out.println("The radius is "+c.getRadius());
    }

We test the program with a Circle object and with a Square object.

    public static void main(String [] args){
        Liskov.program(new Circle(2)); // prints "The radius is 2"
        Liskov.program(new Square(2)); // prints "The radius is -1"
    }
}

What happened ? Intuitively, although Square is a subclass of Circle, Square is not a subtype of Circle because no regular Circle instance would ever have a radius of -1.

Formally, this is a violation of Liskov Substitution Principle.

We have a program defined in terms of Circle and there is no Circle object that can replace new Square(2) (or any Square instance by the way) in this program and leave the behavior unchanged: remember that radius of any Circle is always positive.

Subclass and subtype

Now we know why a subclass is not always subtype. When a subclass is not a subtype, i.e. when there is a LSP violation, the behavior of some programs (at least one) won't always be the expected behavior. This is very frustrating and is usually interpreted as a bug.

In an ideal world, the compiler or interpreter would be able to check is a given subclass is a real subtype, but we are not in an ideal world.

Static typing

If there is some static typing, you are bound by the superclass signature at compile time. Square.getRadius() can't return a String or a List.

If there is no static typing, you'll get an error at runtime if the type of one argument is wrong (unless the typing is weak) or the number of arguments is inconsistent (unless the language is very permissive).

Note about the static typing: there is a mechanism of covariance of the return type (a method of S can return a subclass of the return type of the same method of T) and contravariance of the parameters types (a method of S can accept a superclass of a parameter of the same parameter of the same method of T). That is a specific case of precondition and postcondition explained below.

Design by contract

There's more. Some languages (I think of Eiffel) provide a mechanism to enforce the compliance with the LSP.

Let alone the determination the projection o2 of the initial object o1, we can expect the same behavior of any program if o1 is substituted for o2 if, for any argument x and any method f:

if o2.f(x) is a valid call, then o1.f(x) should also be a valid call (1).
the result (return value, display on console, etc.) of o1.f(x) should be equal to the result of o2.f(x), or at least equally valid (2).
o1.f(x) should let o1 in an internal state and o2.f(x) should let o2 in an internal state so that next function calls will ensure that (1), (2) and (3) will still be valid (3).

(Note that (3) is given for free if the function f is pure. That's why we like to have immutable objects.)

These conditions are about the semantics (what to expect) of the class, not only the syntax of the class. Also, these conditions are very strong. But they can be approximated by assertions in design by contract programming. These assertions are a way to ensure that the semantic of the type is upheld. Breaking the contract leads to runtime errors.

The precondition defines what is a valid call. When subclassing a class, the precondition may only be weakened (S.f accepts more than T.f) (a).
The postcondition defines what is a valid result. When subclassing a class, the postcondition may only be strengthened (S.f provides more than T.f) (b).
The invariant defines what is a valid internal state. When subclassing a class, the invariant must remain the same (c).

We see that, roughly, (a) ensures (1) and (b) ensures (2), but (c) is weaker than (3). Moreover, assertions are sometimes difficult to express.

Think of a class Counter having a unique method Counter.counter() that returns the next integer. How do you write a postcondition for that ? Think of a class Random having a method Random.gaussian() that returns a float between 0.0 and 1.0 . How do you write a postcondition to check that the distribution is gaussian ? It may be possible, but the cost would be so high that we would rely on test rather than on postconditions.

Conclusion

Unfortunately, a subclass is not always a subtype. This can lead to an unexpected behavior -- a bug.

OOP languages provide mechanism to avoid this situation. At syntactic level first. At semantical level too, depending on the programming language: a part of the semantics can be encoded in the text of the program using assertions. But it's up to you to ensure that a subclass is a subtype.

Remember when you began to learn OOP ? "If the relation is IS-A, then use inheritance". That's true the other way: if you use inheritance, be sure that the relation is IS-A.

The LSP defines, at a higher level than assertions, what is a subtype. Assertions are a valuable tool to ensure that the LSP is upheld.

Yaker answered 20/9, 2021 at 10:50 Comment(1)

A subclass is not always a subtype good note – Wild 16/12, 2023 at 6:47

A square is a rectangle where the width equals the height. If the square sets two different sizes for the width and height it violates the square invariant. This is worked around by introducing side effects. But if the rectangle had a setSize(height, width) with precondition 0 < height and 0 < width. The derived subtype method requires height == width; a stronger precondition (and that violates lsp). This shows that though square is a rectangle it is not a valid subtype because the precondition is strengthened. The work around (in general a bad thing) cause a side effect and this weakens the post condition (which violates lsp). setWidth on the base has post condition 0 < width. The derived weakens it with height == width.

Therefore a resizable square is not a resizable rectangle.

Aurelie answered 27/7, 2015 at 21:56 Comment(0)

Would implementing ThreeDBoard in terms of an array of Board be that useful?

Perhaps you may want to treat slices of ThreeDBoard in various planes as a Board. In that case you may want to abstract out an interface (or abstract class) for Board to allow for multiple implementations.

In terms of external interface, you might want to factor out a Board interface for both TwoDBoard and ThreeDBoard (although none of the above methods fit).

Hus answered 11/9, 2008 at 15:28 Comment(1)

I think the example is simply to demonstrate that inheriting from board does not make sense with in the context of ThreeDBoard and all of the method signatures are meaningless with a Z axis. – Boys 11/9, 2008 at 15:32

The clearest explanation for LSP I found so far has been "The Liskov Substitution Principle says that the object of a derived class should be able to replace an object of the base class without bringing any errors in the system or modifying the behavior of the base class" from here. The article gives code example for violating LSP and fixing it.

Tse answered 3/5, 2016 at 19:34 Comment(1)

Please provide the examples of code on stackoverflow. – Haematoblast 3/5, 2016 at 19:51

Let's say we use a rectangle in our code

r = new Rectangle();
// ...
r.setDimensions(1,2);
r.fill(colors.red());
canvas.draw(r);

In our geometry class we learned that a square is a special type of rectangle because its width is the same length as its height. Let's make a Square class as well based on this info:

class Square extends Rectangle {
    setDimensions(width, height){
        assert(width == height);
        super.setDimensions(width, height);
    }
}

If we replace the Rectangle with Square in our first code, then it will break:

r = new Square();
// ...
r.setDimensions(1,2); // assertion width == height failed
r.fill(colors.red());
canvas.draw(r);

This is because the Square has a new precondition we did not have in the Rectangle class: width == height. According to LSP the Rectangle instances should be substitutable with Rectangle subclass instances. This is because these instances pass the type check for Rectangle instances and so they will cause unexpected errors in your code.

This was an example for the "preconditions cannot be strengthened in a subtype" part in the wiki article. So to sum up, violating LSP will probably cause errors in your code at some point.

Jenness answered 9/10, 2017 at 4:26 Comment(0)

LSP says that ''Objects should be replaceable by their subtypes''. On the other hand, this principle points to

Child classes should never break the parent class`s type definitions.

and the following example helps to have a better understanding of LSP.

Without LSP:

public interface CustomerLayout{

    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            return; //it isn`t rendered in this case
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}

Fixing by LSP:

public interface CustomerLayout{
    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            showAd();//it has a specific behavior based on its requirement
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}

Sisneros answered 6/4, 2019 at 12:55 Comment(0)

Liskov Substitution Principle

[SOLID]

Inheritance Subtyping

Wiki Liskov substitution principle (LSP)

Preconditions cannot be strengthened in a subtype.
Postconditions cannot be weakened in a subtype.
Invariants of the supertype must be preserved in a subtype.

Subtype should not require(Preconditions) from caller more than supertype
Subtype should not expose(Postconditions) for caller less than supertype

*Precondition + Postcondition = function (method) types^{[Swift Function type. Swift function vs method]}

//Swift function
func foo(parameter: Class1) -> Class2

//function type
(Class1) -> Class2

//Precondition
Class1

//Postcondition
Class2

Example

//C3 -> C2 -> C1

class C1 {}
class C2: C1 {}
class C3: C2 {}

Preconditions(e.g. function parameter type) can be the same or weaker(strives for -> C1)
Postconditions(e.g. function returned type) can be the same or stronger(strives for -> C3)
Invariant variable^[About] of super type should stay invariant

Swift

class A {
    func foo(a: C2) -> C2 {
        return C2()
    }
}

class B: A {
    override func foo(a: C1) -> C3 {
        return C3()
    }
}

Java

class A {
    public C2 foo(C2 a) {
        return new C2();
    }
}

class B extends A {
    @Override
    public C3 foo(C2 a) { //You are available pass only C2 as parameter
        return new C3();
    }
}

Behavioral subtyping

Wiki Liskov substitution principle (LSP)

Contravariance of method parameter types in the subtype.
Covariance of method return types in the subtype.
New exceptions cannot be thrown by the methods in the subtype, except if they are subtypes of exceptions thrown by the methods of the supertype.

[Variance, Covariance, Contravariance, Invariance]

Flaxseed answered 11/11, 2020 at 15:8 Comment(0)

I encourage you to read the article: Violating Liskov Substitution Principle (LSP).

You can find there an explanation what is the Liskov Substitution Principle, general clues helping you to guess if you have already violated it and an example of approach that will help you to make your class hierarchy be more safe.

Neumann answered 9/9, 2013 at 7:32 Comment(0)

LISKOV SUBSTITUTION PRINCIPLE (From Mark Seemann book) states that we should be able to replace one implementation of an interface with another without breaking either client or implementation.It’s this principle that enables to address requirements that occur in the future, even if we can’t foresee them today.

If we unplug the computer from the wall (Implementation), neither the wall outlet (Interface) nor the computer (Client) breaks down (in fact, if it’s a laptop computer, it can even run on its batteries for a period of time). With software, however, a client often expects a service to be available. If the service was removed, we get a NullReferenceException. To deal with this type of situation, we can create an implementation of an interface that does “nothing.” This is a design pattern known as Null Object,[4] and it corresponds roughly to unplugging the computer from the wall. Because we’re using loose coupling, we can replace a real implementation with something that does nothing without causing trouble.

Callimachus answered 12/8, 2016 at 17:16 Comment(0)

Likov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

Intent - Derived types must be completely substitute able for their base types.

Example - Co-variant return types in java.

Sascha answered 23/9, 2017 at 19:26 Comment(0)

Here is an excerpt from this post that clarifies things nicely:

[..] in order to comprehend some principles, it’s important to realize when it’s been violated. This is what I will do now.

What does the violation of this principle mean? It implies that an object doesn’t fulfill the contract imposed by an abstraction expressed with an interface. In other words, it means that you identified your abstractions wrong.

Consider the following example:

interface Account
{
    /**
     * Withdraw $money amount from this account.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}
class DefaultAccount implements Account
{
    private $balance;
    public function withdraw(Money $money)
    {
        if (!$this->enoughMoney($money)) {
            return;
        }
        $this->balance->subtract($money);
    }
}

Is this a violation of LSP? Yes. This is because the account’s contract tells us that an account would be withdrawn, but this is not always the case. So, what should I do in order to fix it? I just modify the contract:

interface Account
{
    /**
     * Withdraw $money amount from this account if its balance is enough.
     * Otherwise do nothing.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}

Voilà, now the contract is satisfied.

This subtle violation often imposes a client with the ability to tell the difference between concrete objects employed. For example, given the first Account’s contract, it could look like the following:

class Client
{
    public function go(Account $account, Money $money)
    {
        if ($account instanceof DefaultAccount && !$account->hasEnoughMoney($money)) {
            return;
        }
        $account->withdraw($money);
    }
}

And, this automatically violates the open-closed principle [that is, for money withdrawal requirement. Because you never know what happens if an object violating the contract doesn't have enough money. Probably it just returns nothing, probably an exception will be thrown. So you have to check if it hasEnoughMoney() -- which is not part of an interface. So this forced concrete-class-dependent check is an OCP violation].

This point also addresses a misconception that I encounter quite often about LSP violation. It says the “if a parent’s behavior changed in a child, then, it violates LSP.” However, it doesn’t — as long as a child doesn’t violate its parent’s contract.

Polysyllabic answered 12/8, 2018 at 17:10 Comment(0)

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Actually, the accepted answer is not a counterexample for the Liskov principle. A square naturally is a specific rectangle, so it makes perfect sense that inherits from the class rectangle. You simply need to implement it in this way:

@Override
public void setHeight(double height) {
   this.height = height;
   this.width = height; // since it's a square
}

@Override
public void setWidth(double width) {
   setHeight(width);
}

So, having provided a good example, this, however, is a counterexample:

class Family:
-- getChildrenCount()

class FamilyWithKids extends Family:
-- getChildrenCount() { return childrenCount; } // always > 0

class DeadFamilyWithKids extends FamilyWithKids:
-- getChildrenCount() { return 0; }
-- getChildrenCountWhenAlive() { return childrenCountWhenAlive; }

In this implementation, DeadFamilyWithKids cannot inherit from FamilyWithKids since getChildrenCount() returns 0, while from FamilyWithKids it should always return something greater 0.

Ebullience answered 14/12, 2021 at 23:53 Comment(0)

Let me try, consider an interface:

interface Planet{
}

This is implemented by class:

class Earth implements Planet {
    public $radius;
    public function construct($radius) {
        $this->radius = $radius;
    }
}

You will use Earth as:

$planet = new Earth(6371);
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

Now consider one more class which extends Earth:

class LiveablePlanet extends Earth{
   public function color(){
   }
}

Now according to LSP, you should be able to use LiveablePlanet in place of Earth and it should not break your system. Like:

$planet = new LiveablePlanet(6371);  // Earlier we were using Earth here
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

Examples taken from here

Stoker answered 26/4, 2019 at 6:59 Comment(1)

Poor example. Earth is an instance of plant, why would it get derived from it? – Unsought 3/5, 2019 at 15:46

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Bad example

Good example

A Simple Example of a Violation of LSP

Square and Rectangle, a More Subtle Violation.

Violation Example:

Respected Example:

Example

Circle and ColoredCircle

Counter Example

Circle and Square

The violation of the LSP

Subclass and subtype

Static typing

Design by contract

Conclusion

Recommended topics

Hot tags

`Circle` and `ColoredCircle`

`Circle` and `Square`