5/17/2015 OO Design: Liskov Substitution Principle 1

5/17/2015 OO Design: Liskov Substitution Principle 2 Liskov Substitution Principle  But we must be careful when we implement subclass to ensure that we don’t violate the LSP public class Rectangle { private double width, height; Rectangle(double w, double h) { width = w; height = h; } public double area() { return width * height; } public void setWidth(double w) { width = w;} public void setHeight(double h){ height = h;} public double getWidth() { return width; } public double getHeight() { return height;} }

5/17/2015 OO Design: Liskov Substitution Principle 3 LSP Example public class Square extends Rectangle { Square(double s) { super(s,s); } public void setWidth(double w) { super.setWidth(w); super.setHeight(w);} public void setHeight(double h){ super.setWidth(h); super.setHeight(h);} }

5/17/2015 OO Design: Liskov Substitution Principle 4 LSP Example public class TestRectangle { public static void testLSP(Rectangle r) { r.setWidth(4.0); r.setHeight(5.0); System.out.println(r.area()); assert(r.area()= 20); }

5/17/2015 OO Design: Liskov Substitution Principle 5 What Went Wrong?  Consider the postcondition for setWidth in classes Rectangle and Square:  Rectangle: width == w && height == old.height  Square: width == w && height == w  The postcondition for Square is weaker than the postcondition for Rectangle because it does not attempt to enforce the clause (height == old.height)

5/17/2015 OO Design: Liskov Substitution Principle 6 Rule  When you override a method in a base class, the precondition of the overriding method should be weaker than the precondition of the overriden method: The more useful a procedure is for clients The more difficult it is to implement correctly “Weaker” means the derived class should consider more inputs to the overriding method

5/17/2015 OO Design: Liskov Substitution Principle 7 Rule  When you override a method in a base class, the postcondition of the overriding method should be stronger than the postcondition of the overriden method: “Stronger” means the derived class should produce less outputs from the overriding method

5/17/2015 OO Design: Liskov Substitution Principle 8 So, void testRectangleSetWidth(Rectangle rec) { double oldHeight = rec.getHeight(); rec.setWidth(5); // postconditions of Rectangle assertTrue (5 == rec.getWidth() && oldHeight == rec.getHeight()); }

5/17/2015 OO Design: Liskov Substitution Principle 9 Subtype Substitution  If B is a subtype of A, everywhere the code expects an A, a B can be used instead  Examples: Cell c = c1; c1 must be a subtype of Cell (note A is a subtype of A) Cell c = new ConwayLifeCell (); ConwayLifeCell c = new Cell ();

5/17/2015 OO Design: Liskov Substitution Principle 10 Inheritance  To implement a subtype, it is often useful to use the implementation of its supertype  This is also called “subclassing” class B extends A B is a subtype of A B inherits from A class C implements F C is a subtype of F both subtyping and inheritance just subtyping No way to get inheritance without subtyping in Java

5/17/2015 OO Design: Liskov Substitution Principle 11 How do we know if saying B is a subtype of A is safe? Substitution Principle: If B is a subtype of A, everywhere the code expects an A, a B can be used instead and the program still satisfies its specification

5/17/2015 OO Design: Liskov Substitution Principle 12 Subtype Condition 1: Signature Rule We can use a subtype method where a supertype methods is expected: Subtype must implement all of the supertype methods Argument types must not be more restrictive Result type must be at least as restrictive Subtype method must not throw exceptions that are not subtypes of exceptions thrown by supertype

5/17/2015 OO Design: Liskov Substitution Principle 13 Signature Rule class A { public R A m (P A p) ; } class B extends A { public R B m (P B p) ; } R B must be a subtype of R A : R B <= R A P B must be a supertype of P A : P B >= P A

5/17/2015 OO Design: Liskov Substitution Principle 14 Substitution Mystery …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; …(anything could be here) mt1 = mt2.m (mt3); If the Java compiler accepts this code, which of these are guaranteed to be true: a.The static type of mt2 is MysteryType2 b.At the last statement, the run-time type of mt2 is MysteryType2 c.MysteryType2 has a method named m d.The MysteryType2.m method takes a parameter of type MysteryType3 e.The MysteryType2.m method returns a subtype of MysteryType1 f.After the last statement, the run-time type of mt1 is MysteryType1

5/17/2015 OO Design: Liskov Substitution Principle 15 …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; …(anything could be here) mt1 = mt2.m (mt3); a.The static type of mt2 is MysteryType2 b.At the last statement, the run-time type of mt2 is MysteryType2 c.MysteryType2 has a method named m d.The MysteryType2.m method takes a parameter of type MysteryType3 e.The MysteryType2.m method returns a subtype of MysteryType1 f.After the last statement, the run-time type of mt1 is MysteryType1 TRUE: the static type is obvious from the declaration. FALSE: we only know the run-time type <= MysteryType2 TRUE FALSE: we only know it takes a parameter >= MysteryType3 TRUE: the assignment type checking depends on this FALSE: we only know that the run-time type <= MysteryType1