The Substitution Principle SWE 332 – Fall 2010

2 Liskov Substitution Principle In any client code, if subtype object is substituted for supertype object, the client’s expectations are still met Simple example: Object o = getNewObject(); // client call Case 1: public Object getNewObject() {...} Case 2: public String getNewObject() {...}

3 Dynamic Dispatching Object[] x = new Object[2]; X[0] = new String(“abc”); X[1] = new Integer(1); for(int i=0; i<x.length;i++) System.out.println(x[i].toString()); Compiler does not complain Apparent type is fine! Which toString method is called? Object.toString() String.toString() Integer.toString() At run time, “best fit” code is called.

4 Two valid reasons to subtype Multiple implementations Ideally, client unaware of multiple implementations Example: Set interface HashSet, TreeSet implementations Extended Behavior Usual reason for subtyping Note what is not a reason: Making implementer’s life easier

5 Extended behavior Extended Behavior Specialize the behavior of supertype Classic ‘IS A’ relationship Additional state (abstract or representation) Warning: Harder than it looks! Vehicle Car Bike Constraint View: for contracts CAR Object View: for rep Vehicle

6 Analyzing subtype METHODS Subtypes behavior must support supertype behavior Liskov Substitution Principle Three rules for subtype methods: 1. Signature Rule 2. Methods Rule 3. Properties Rule

7 Signature Rule Guaranteed by Compiler Subtypes must have all methods of supertype Sounds obvious, but programmers often try to get around this Signatures of methods must be compatible with supertype signature Typically, return types are the same Covariance: Subclass may return a subtype Exceptions: Signature Rule allows fewer exceptions But Methods Rule may be in conflict Methods Rule always has priority

8 More concretely… public class (alt. interface) Super{ /** * m() is defined … (pre) * m() does the following things (post) … (post) */ public T1 m (T2: t2, T3: t3) throws E1, E2… } public class Sub extend (alt. implements) Super{ /** ??? */ public T1 m(T2: t2, T3: t3) throws E1, E2… }

9 Methods Rule When object belongs to subtype, subtype method is called Supertype specifications are necessarily inherited For analysis, consult pre/post See prior slide

10 Methods Rule Must maintain the contract! 1. Precondition rule: What can a subclass do with preconditions in supertype spec? 2. Post condition rule: What can a subclass do with postconditions in supertype spec?

11 Precondition rule Subtype is allowed to weaken the precondition Formally: If pre_super, then pre_sub Super //pre x > 5 Case 1: Sub //pre x > 6 Case 2: Sub // pre x > 4 x>5  x>4?Which is weaker? x>5  x>6? Not checked by compiler

12 Post condition rule Subtype is allowed to strengthen the post condition in a consistent way Formally: If pre_super, and sub_post, then super_post Super: // post: returns y < 5 Sub: //post: returns y < 4 Sub: //post: returns y < 6 Which one is a stronger condition?

13 Same Diagram as Method Verification SuperType Method Contract Subtype Method Contract AF() Supertype State (Post-Super)Supertype State (Pre-Super) Subtype State (Post-Sub) Subtype State (Pre-Sub) ?

14 Examples Super public void addZero() //pre: this is not empty //post: add zero to this public void addZero() throws ISE //pre: this is not empty //post: add zero to this Sub public void addZero() //post: add zero to this public void addZero() throws ISE //post: if this is empty, throw ISE else add zero to this Satisfies Signature and Method rules Satisfies Signature and Method rules

15 More examples Super public void addZero() //pre: this is not empty //post: add zero to this public void addZero() throws ISE //post: if this is empty, throws ISE // else add zero to this Sub public void addZero() throws ISE //post: add zero to this public void addZero() //post: add zero to this Does not satisfy Signature rule Does not satisfy Postcondition part of methods rule

16 Client code: Liskov Substitution Principle private void foo { … try{ o.addZero(); } catch (ISE e){ //do something: Client expects to get here! }

17 Methods rule vs. Properties rule Methods rule is for single method invocation Properties rule about general object behavior Invariants: Example: Sets do not contain duplicates Evolution properties: Example: Monotone sets only grow No remove() method allowed Properties must be explicit (i.e. in the JavaDoc)

18 More About Properties Rule Collection c =...; c.add (“cat”); c.remove(“cat”); // consider the following observer call: // What is behavior if c is a Set? // What is behavior if c is a Bag? if (c.contains(“cat”) {... } // Such “algebraic” relations are extremely useful for testing