The Substitution Principle SWE 332 Fall 2010 Liskov

The Substitution Principle SWE 332 – Fall 2010

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

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]. to. String()); n Compiler does not complain n n Which to. String method is called? n n Apparent type is fine! Object. to. String() String. to. String() Integer. to. String() At run time, “best fit” code is called. 3

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

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

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

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

More concretely… public class (alt. interface) Super{ /** * m() is defined … (pre) * m() does the following things (post) * @throws … (post) */ public T 1 m (T 2: t 2, T 3: t 3) throws E 1, E 2… } public class Sub extend (alt. implements) Super{ /** ? ? ? */ public T 1 m(T 2: t 2, T 3: t 3) throws E 1, E 2… } 8

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

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

Precondition rule n n Subtype is allowed to weaken the precondition Formally: n n n n 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 11

Post condition rule n n Subtype is allowed to strengthen the post condition in a consistent way Formally: n n n 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? 12

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

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

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

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

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

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