19

I read that Liskov's substitution principle is violated if :

  1. Preconditions are strengthened, or

  2. Postconditions are weakened

But I don't get fully yet how these two points would violate Liskov substitution principle. Can some one please explain with an example. Specifically, how would any one of the above conditions cause a situation where a subclass object can not be substituted for a superclass object?

28
  1. Assume your baseclass works with a member int. Now your subtype 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.

  2. Likewise, assume the same scenario, but the base class used to guarantee that the member would be positive after being called. Then the subtype changes the behavior to allow negative ints. Code that works on the object (and assumes that the post-condition is a positive int) is now broken since the post-condition is not upheld.

These are of course trivial examples, but the concept holds. Stuff like leaving a file/database connection open is an example of an eased post-condition that leads to issues.

1

enter image description here

Invariant - Template of SelfDrivingVehicle which remain unchanged in all subtypes i.e. Order in which it executes the overridden behaviors to reach to destination.

Lets Assume one more method Here

           -List<SelfDrivingVehicle> vehicles 
           +Add(SelfDrivingVehicle vehicle)
            vehicles.add(vehicle)

Precondition - SelfDriveVehicle the Base Type has no vehicles in it(here the context is Add) and its in Weakened Precondition which can't be altered by any of its sub types by changing the property vehicles and Strengthen it Explicitly. Any of the sub types may only invoke Add.

Postcondition - Once Add is invoked Base Type is in Strengthened Postcondition which can't be weakened by sub types by altering the value of vehicles.

State of Base Type comes back to its Original State once the Add Behavior is invoked.

-1

This example is pretty much beaten to death, but consider the Square/Rectangle or Circle/Ellipse possibility. Suppose you have a base class Rectangle that defines an object with a length and width. If you have a Square class that inherits the Rectangle class, it would have a rule in its setter/getter that would require that any change to length or width would alter its counterpart. These dimensional requirements strengthen pre-conditions because a rectangle substituted for a square would be missing these dimensional requirements. Suppose you reverse the inheritance so that a Rectangle inherits a Square, you would be weakening post conditions by relaxing the dimensional requirements to allow the Rectangle to behave independently.

However, if you were to remove the dimensional change capability, the substitution principle holds because if neither a Rectangle nor a Square may change dimensions, then they have equal pre and post conditions regardless of inheritance. Both have a length, both have a width, and neither can alter those values.

ref: Wikipedia - http://en.wikipedia.org/wiki/Liskov_substitution_principle

  • 1
    Unfortunately that example has nothing to do with formal verification. There are no contracts. – Frank Hileman Oct 19 '17 at 17:20

protected by gnat Oct 11 '18 at 9:16

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.