Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation...

38
toad Fall 2013 © 2012-13 C Garrod, J Aldrich, and W Scherlis School of Computer Science Principles of Software Construction: Objects, Design and Concurrency Encapsulation and Inheritance Jonathan Aldrich Charlie Garrod 15-214

Transcript of Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation...

Page 1: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

 toad    

Fall  2013  

© 2012-13 C Garrod, J Aldrich, and W Scherlis

School of Computer Science

Principles of Software Construction: Objects, Design and Concurrency Encapsulation and Inheritance

Jonathan Aldrich Charlie Garrod

15-214

Page 2: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

2 15-­‐214    Garrod  

Administrivia

• Office hours updates (all times p.m.) § Sunday 8 – 10: Mat in GHC 41xx § Monday 8 – 10: Shannon in GHC 41xx §  Tuesday 6 – 8: Dan in GHC 41xx §  Tuesday 8 – 10: Alex in GHC 41xx § Wednesday 2:30 – 3:30: Jonathan in Wean 4216 § Wednesday 6 – 8: Bailey in GHC 41xx §  Thursday 7 – 9: Beth Anne in GHC 41xx §  Friday 1:30 – 3: Charlie in Wean 5101

• Homework 1 due next Tuesday…

Page 3: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

3 15-­‐214    Garrod  

Homework 1: Representing graphs

Two common representations Ø Adjacency matrix Ø Adjacency list

Adjacency matrix Adjacency list

b

d

c

a

0 1 0 0

0 0 1 0

1 0 0 1

1 0 0 0

a

b

c

d

a b c d a

b

c

d

b

c

a d

a

sour

ce

target

Page 4: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

4 15-­‐214    Garrod  

Key concepts from Thursday

Page 5: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

5 15-­‐214    Garrod  

Key concepts from Thursday

• Objects, classes, and references

• Encapsulation and visibility

• Polymorphism §  Interfaces §  Introduction to method dispatch

• Object equality

Page 6: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

6 15-­‐214    Garrod  

E.g., a Dog interface

Dog

Chiuaua GermanShepherd …

public interface Dog { public String getName(); public String getBreed(); public void bark(); }

public class Chiuaua implements Dog { public String getName() { return "Bob"; } public String getBreed() { return "Chiuaua"; } public void bark() { /* How do I bark? */ } }

Page 7: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

7 15-­‐214    Garrod  

A preview of inheritance

Dog

AbstractDog

Chiuaua GermanShepherd …

“parent” or

“superclass”

“child” or

“subclass”

Page 8: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

8 15-­‐214    Garrod  

Key concepts for today

• Encapsulation, revisited §  Packages

• Name and visibility management • Qualified names

§ General design principles

• Inheritance and polymorphism §  For maximal code re-use § Diagrams to show the relationships between classes §  Polymorphism and its alternatives §  Types and type-checking § Method dispatch, revisited § Etc.

Page 9: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

9 15-­‐214    Garrod  

Programming languages: a complex view

Small-scale Larger-scale

Data Primitives Arrays Structures

Objects Heaps

Control Basic (if, while, ;) Function/method calls

Method dispatch Concurrency

Naming and Reference

Local variables Parameters

Package, imports Visibility Qualification

Page 10: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

10 15-­‐214    Garrod  

Java packages

• Packages divide the Java namespace to organize related classes

package edu.cmu.cs.cs214.geo;

class Point {

private int x, y;

public int getX() { return x; } // a method; getY() is similar

public Point(int px, int py) { x = px; y = py; } // …

}

class Rectangle {

private Point origin;

private int width, height;

public Point getOrigin() { return origin; }

public int getWidth() { return width; }

// …

}

Page 11: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

11 15-­‐214    Garrod  

Packages are another mechanism of encapsulation

• Visibility of names: §  public: visible everywhere §  protected: visible within package and also to subclasses § default (no modifier): visible only within package §  private: visible only within class

Modifier Class Package Subclass World public Y Y Y Y protected Y Y Y N default Y Y N N private Y N N N

Page 12: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

12 15-­‐214    Garrod  

Packages and qualified names

• E.g., three ways to refer to a java.util.Queue: § Use the full name:

java.util.Queue q = …;!q.add(…);!

§  Import java.util.Queue, then use the unqualified name: import java.util.Queue; Queue q = …;!

§  Import the entire java.util package: import java.util.*;!Queue q = …;!

• Compiler will warn about ambiguous references § Must then use qualified name to disambiguate

Page 13: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

13 15-­‐214    Garrod  

Encapsulation design principles

• Restrict accessibility as much as possible § Make data and methods private unless you have a reason to make it more visible

"The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details." -- Josh Bloch

Page 14: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

14 15-­‐214    Garrod  

An introduction to inheritance

• A dog of an example: § Dog.java § AbstractDog.java § Chiuaua.java § GermanShepherd.java

• Typical roles: § An interface define expectations / commitment for clients § An abstract class is a convenient hybrid between an interface and a full implementation

§ Subclass overrides a method definition to specialize its implementation

Page 15: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

15 15-­‐214    Garrod  

Inheritance: a glimpse at the hierarchy

• Examples from Java §  java.lang.Object  § Collections library

Page 16: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

16 15-­‐214    Garrod  

JavaCollection API (excerpt)

Collection

List Set AbstractCollection

AbstractList

LinkedList

Vector

HashSet

AbstractSequentialList

AbstractSet

Cloneable

ArrayList

interfaces

Page 17: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

17 15-­‐214    Garrod  

Benefits of inheritance

• Reuse of code

• Modeling flexibility

• A Java aside: § Each class can directly extend only one parent class § A class can implement multiple interfaces

Page 18: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

18 15-­‐214    Garrod  

Aside: UML class diagram notation

«interface»  Dog    getName()  :  String  getBreed()  :  String  bark()  :  String  setName(name  :  String)  toString()  :  String  

AbstractDog  -­‐  name  :  String    -­‐  breed  :  String    +  getName()  :  String  +  getBreed()  :  String  +  bark()  :  String  +  setName(name  :  String)  #  setBreed(breed  :  String)  +  toString()  :  String  

GermanShephard    bark()  :  String  play()  

«interface»  brand  

Name  of  class  or  interface  in  top  compartment  

Return  type  comes  aDer  

method  or  field  Methods  in  boGom  

compartment   Dashed  line,  open  triangle  arrowhead  for  implements  

Solid  line,  open  triangle  arrowhead  

for  extends  

Italics  means  abstract  

Italics  means  abstract  

OpMonal  visibility:  +  for  public  -­‐   for  private  #  for  protected  ~  for  package  (not  used  much)  

Fields  in  middle  compartment  

Page 19: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

19 15-­‐214    Garrod  

Another example: different kinds of bank accounts

«interface»  CheckingAccount    getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  getFee()  :  float  

«interface»  SavingsAccount    getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  getInterestRate()  :  float  

Page 20: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

20 15-­‐214    Garrod  

A better design: An account type hierarchy

«interface»  Account    getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

«interface»  CheckingAccount    getFee()  :  float  

«interface»  SavingsAccount    getInterestRate()  :  float  

«interface»  InterestCheckingAccount      

SavingsAccount  is  a  subtype  of  

Account.    Account  is  a  supertype  of  SavingsAccount.  

MulQple  interface  extension  

CheckingAccount  extends  Account.  All  methods  from  

Account  are  inherited  (copied  to  CheckingAccount)  

If  we  know  we  have  a  CheckingAccount,  addiQonal  methods  

are  available.  

Page 21: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

21 15-­‐214    Garrod  

A better design: An account type hierarchy

«interface»  Account    getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

«interface»  CheckingAccount    getFee()  :  float  

«interface»  SavingsAccount    getInterestRate()  :  float  

«interface»  InterestCheckingAccount      

SavingsAccount  is  a  subtype  of  

Account.    Account  is  a  supertype  of  SavingsAccount.  

MulQple  interface  extension  

CheckingAccount  extends  Account.  All  methods  from  

Account  are  inherited  (copied  to  CheckingAccount)  

If  we  know  we  have  a  CheckingAccount,  addiQonal  methods  

are  available.  

public interface CheckingAccount ! extends Account {! …!} !

public interface InterestCheckingAccount! extends CheckingAccount, SavingsAccount {! …!} !

Page 22: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

22 15-­‐214    Garrod  

The power of object-oriented interfaces

• Polymorphism § Different kinds of objects can be treated uniformly by client code • e.g., a list of all accounts

§ Each object behaves according to its type • If you add new kind of account, client code does not change

§ Consider this pseudocode:

§ See the DogWalker example

If today is the last day of the month:! For each acct in allAccounts:! acct.monthlyAdjustment();! !

Page 23: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

23 15-­‐214    Garrod  

One implementation: Just use interface inheritance

«interface»  Account    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

«interface»  CheckingAccount    

getFee()  :  float  

«interface»  SavingsAccount    

getInterestRate()  :  float  

«interface»  InterestCheckingAccount      

CheckingAccountImpl    

…  

SavingsAccountImpl    

…  

InterestCheckingAccountImpl    

…  

Page 24: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

24 15-­‐214    Garrod  

Better: Reuse abstract account code

public abstract class AbstractAccount implements Account { protected float balance = 0.0; public float getBalance() { return balance; } abstract public void monthlyAdjustment(); // other methods…

} public class CheckingAccountImpl

extends AbstractAcount implements CheckingAccount { public void monthlyAdjustment() { balance -= getFee(); } public float getFee() { /* fee calculation */ }

}

«interface»  Account    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

CheckingAccountImpl    

monthlyAdjustment()  getFee()  :  float  

AbstractAccount    

#  balance  :  float    

+  getBalance()  :  float  +  deposit(amount  :  float)  +  withdraw(amount  :  float)  :  boolean  +  transfer(amount  :  float,  

 target  :  Account)  :  boolean  +  monthlyAdjustment()  

«interface»  CheckingAccount    

getFee()  :  float  

Page 25: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

25 15-­‐214    Garrod  

Better: Reuse abstract account code

public abstract class AbstractAccount implements Account { protected float balance = 0.0; public float getBalance() { return balance; } abstract public void monthlyAdjustment(); // other methods…

} public class CheckingAccountImpl

extends AbstractAcount implements CheckingAccount { public void monthlyAdjustment() { balance -= getFee(); } public float getFee() { /* fee calculation */ }

}

«interface»  Account    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

CheckingAccountImpl    

monthlyAdjustment()  getFee()  :  float  

AbstractAccount    

#  balance  :  float    

+  getBalance()  :  float  +  deposit(amount  :  float)  +  withdraw(amount  :  float)  :  boolean  +  transfer(amount  :  float,  

 target  :  Account)  :  boolean  +  monthlyAdjustment()  

«interface»  CheckingAccount    

getFee()  :  float  

protected  elements  are  visible  in  subclasses  

an  abstract  class  is  missing  the  

implemenQon  of  one  or  more  methods  

an  abstract  method  is  leV  to  be  implemented  in  a  

subclass  

no  need  to    define  getBalance()  –  the  code  is  

inherited  from  AbstractAccount  

Page 26: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

26 15-­‐214    Garrod  

Inheritance and subtyping

• Inheritance is for code reuse § Write code once and only once § Superclass features implicitly available in subclass

• Subtyping is for polymorphism § Accessing objects the same way, but getting different behavior

§ Subtype is substitutable for supertype

class  A  extends  B  

class  A  implements  I  class  A  extends  B  

Page 27: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

27 15-­‐214    Garrod  

Challenge: Is inheritance necessary?

• Can we get the same amount of code reuse without inheritance?

«interface»  Account    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

«interface»  CheckingAccount    

getFee()  :  float  

«interface»  SavingsAccount    

getInterestRate()  :  float  

«interface»  InterestCheckingAccount      

Page 28: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

28 15-­‐214    Garrod  

Reuse via composition and forwarding

«interface»  Account    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean  monthlyAdjustment()  

«interface»  CheckingAccount    

getFee()  :  float  

CheckingAccountImpl    

monthlyAdjustment()  {  …  }  getFee()  :  float  {  …  }  getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean    

BasicAccountImpl    

balance  :  float    

getBalance()  :  float  deposit(amount  :  float)  withdraw(amount  :  float)  :  boolean  transfer(amount  :  float,  

 target  :  Account)  :  boolean    

public class CheckingAccountImpl! implements CheckingAccount {! BasicAccountImpl basicAcct = new(…);! public float getBalance() {! return basicAcct.getBalance();! }! // …!

CheckingAccountImpl  has  a  BasicAccountImpl  

Page 29: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

29 15-­‐214    Garrod  

Inheritance vs. composition

• Composition can be cleaner than inheritance § Reused code in a separate object

• Inheritance has less boilerplate code § No forwarding functions § Easier to avoid recursive dependencies

• Inheritance violates principles of encapsulation § Subclass dependent on superclass implementation

• Advice: Use inheritance sparingly § Before you define a class Foo to extend Bar, ask: "Is every Foo really a Bar?"

Page 30: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

30 15-­‐214    Garrod  

Extended re-use with super!

public abstract class AbstractAccount implements Account {!!protected float balance = 0.0;!

!public boolean withdraw(float amount) {!

! // withdraws money from account (code not shown)!

!}!

}!

!

public class ExpensiveCheckingAccountImpl!

! !extends AbstractAcount implements CheckingAccount {!

!public boolean withdraw(float amount) {!

! !balance -= HUGE_ATM_FEE;!

! !boolean success = super.withdraw(amount)!

! !if (!success)!

! ! !balance += HUGE_ATM_FEE;!

! !return success;!

!}!

}!

 Overrides  withdraw  but  also  uses  the  superclass  withdraw  method  

Page 31: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

31 15-­‐214    Garrod  

Constructor calls with this and super!

public class CheckingAccountImpl!

! !extends AbstractAcount implements CheckingAccount {!

!

!private float fee;!

!

!public CheckingAccountImpl(float initialBalance, float fee) {!

! !super(initialBalance);!

! !this.fee = fee;!

!}!

!

!public CheckingAccountImpl(float initialBalance) {!

! !this(initialBalance, 5.00);!

!}!

!/* other methods… */ }!

!

Invokes  another  constructor  in  this  

same  class  

Invokes  a  constructor  of  the  superclass.  Must  be  the  first  statement  of  the  

constructor.  

Page 32: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

32 15-­‐214    Garrod  

Inheritance Details: final!

• A final class: cannot extend the class §  e.g., public final class CheckingAccountImpl { …!

• A final method: cannot override the method

• A final field: cannot assign to the field §  (except to initialize it)

• Why might you want to use final in each of the above cases?

Page 33: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

33 15-­‐214    Garrod  

Type-casting in Java

• Sometimes you want a different type than you have §  e.g., !float pi = 3.14;! !int indianaPi = (int) pi;!

• Useful if you know you have a more specific subtype: §  e.g., Account acct = …;! CheckingAccount checkingAcct = ! (CheckingAccount) acct;! float fee = checkingAcct.getFee(); § Will get a ClassCastException if types are incompatible

Page 34: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

34 15-­‐214    Garrod  

Inheritance Details: instanceof!

• Operator that tests whether an object is of a given class Account acct = …;!float adj = 0.0;!if (acct instanceof CheckingAccount) {! checkingAcct = (CheckingAccount) acct;!! adj = checkingAcct.getFee();!}!

• Advice: avoid instanceof if possible !

Page 35: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

35 15-­‐214    Garrod  

Typechecking

• The key idea: Analyze a program to determine whether each operation is applicable to the types it is invoked on

• Benefits: §  Finds errors early

• e.g., int h = “hi” / 2;!§ Helps document program code

• e.g., baz(frob) { /* what am I supposed to do ! ! ! ! with a frob? */ }! void baz(Car frob) { /* oh, look, ! I can drive it! */ }!!

Page 36: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

36 15-­‐214    Garrod  

Value Flow and Subtyping

• Value flow: assignments, passing parameters §  e.g., Foo f = expression;!§ Determine the type Tsource of the source expression § Determine the type Tdest of the destination variable f!§ Check that Tsource is a subtype of Tdest

• Subtype relation A <: B § A <: B if A extends B or A implements B § Means you can substitute a thing of type A for a thing of type B

• Subtypes are: § Reflexive: A <: A §  Transitive: if A <: B and B <: C then A <: C

Page 37: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

37 15-­‐214    Garrod  

Typechecking expressions in Java

• Base cases: §  variables and fields

• the type is explicitly declared § Expressions using new ...()!

• the type is the class being created §  Type-casting

• the type is the type forced by the cast

• For method calls, e.g., e1.m(e2) 1.  Determine the type T1 of the receiver expression e1 2.  Determine the type T2 of the argument expression e2 3.  Find the method declaration m in type T1 (or

supertypes), using dispatch rules 4.  The type is the return type of the method declaration

identified in step 3

Page 38: Principles of Software Construction: Objects, Design and ...aldrich/214/slides/03 Encapsulation and...Principles of Software Construction: Objects, Design and Concurrency Encapsulation

38 15-­‐214    Garrod  

Subtyping Rules

• If a concrete class B extends type A § B must define or inherit all concrete methods declared in A

• If B overrides a method declared in supertype A §  The argument types must be the same as those in A’s method

§  The result type must be a subtype of the result type from A’s method

§ Advice: Always use @Override  

• Behavioral subtyping §  If B overrides a method declared in A, it should conform to the specification from A

§  If Cowboy.draw() overrides Circle.draw(), somebody gets hurt!