Principles of Software Construction: Objects, Design and Concurrency. Packages and Polymorphism. toad Fall 2012

Transcription

1 Principles of Software Construction: Objects, Design and Concurrency Packages and Polymorphism toad Fall 2012 Jonathan Aldrich Charlie Garrod School of Computer Science 2012 C Garrod, J Aldrich, and W Scherlis

2 Homework 1: Representing graphs Two common representations Ø Adjacency matrix Ø Adjacency list b a c d source Adjacency matrix Adjacency list a b c d a b c d target a b c b c a d d a toad 2

3 Lab work Attending recitation (Wednesday) is required Attending lab (Monday) is not required But you still must complete the lab work Handout via SVN (trunk/lab/01) later this week Commit due Tuesday (11 Sept) 11:59 p.m. toad 3

4 Key concepts from Tuesday Exceptions Classes, revisited Objects vs. classes Null references Mutability Abstract vs. implementation Static fields and methods toad 4

5 An earlier aside: Overloading! Multiple methods of the same name but different argument types toad 5

6 An earlier aside: Using a static method! Syntax is: CLASSNAME.METHODNAME(ARGS) e.g.: String s = null;! int i = 42;! s = String.valueOf(i);!! toad 6

7 Key concepts for today Packages Name and visibility management Qualified names Inheritance and polymorphism For maximal code re-use Diagrams to show the relationships between classes Polymorphism and its alternatives Method dispatch, revisited Etc. toad 7

8 Recall: Inheritance, class hierarchy Dog AbstractDog parent or superclass Chiuaua GermanShepherd child or subclass toad 8

9 Programming languages: a complex view Small-scale Data Primitives Arrays Structures Control Basic (if, while, ;) Function/method calls Larger-scale Objects Heaps Method dispatch Concurrency Naming and Reference Local variables Parameters Package, imports Visibility Qualification toad 9

10 An earlier code example, revisited package edu.cmu.cs.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; } // } toad 10

11 Packages and visibility Packages divide the Java namespace to organize related classes Visibility of names: public: visible everywhere private: visible only within class default (no modifier needed): visible only within package protected: visible within package and also to subclasses 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 toad 11

12 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 toad 12

13 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 Can override a method definition to specialize its implementation toad 13

14 Inheritance: a glimpse at the hierarchy Examples from Java Collections library [next slide] Graphics objects java.lang.object Benefits and risks of inheritance Reuse of code Modeling flexibility Specialization ç è Subtyping Multiple inheritance In Java: Can extend only one parent class Can implement multiple interface toad 14

15 JavaCollection API (excerpt) interfaces Collection AbstractCollection List Set AbstractList AbstractSet Vector Cloneable AbstractSequentialList ArrayList LinkedList HashSet toad 15

16 Inheritance: a glimpse at the hierarchy Examples from Java Collections library Graphics objects java.lang.object Benefits and risks of inheritance Reuse of code Modeling flexibility Specialization ç è Subtyping Multiple inheritance In Java: Can extend only one parent class Can implement multiple interface toad 16

17 Aside: UML class diagram notation «interface» brand Methods in bogom compartment Fields in middle compartment OpMonal visibility: + for public - for private # for protected ~ for package (not used much) Dashed line, open triangle arrowhead for implements bark() : String play() «interface» Dog getname() : String getbreed() : String bark() : String setname(name : String) tostring() : String - name : String - breed : String AbstractDog + getname() : String + getbreed() : String + bark() : String + setname(name : String) # setbreed(breed : String) + tostring() : String GermanShephard Name of class or interface in top compartment Return type comes ader method or field Solid line, open triangle arrowhead for extends Italics means abstract toad 17

18 Consider different kinds of bank accounts: «interface» CheckingAccount getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, getfee() : float «interface» SavingsAccount getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, getinterestrate() : float toad 18

19 A better design: An account type hierarchy «interface» Account CheckingAccount extends Account. All methods from Account are inherited (copied to CheckingAccount) getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() SavingsAccount is a subtype of Account. Account is a supertype of SavingsAccount. «interface» CheckingAccount getfee() : float «interface» SavingsAccount getinterestrate() : float If we know we have a CheckingAccount, addiponal methods are available. «interface» InterestCheckingAccount MulPple interface extension toad 19

20 A better design: An account type hierarchy «interface» Account public interface CheckingAccount! CheckingAccount extends Account getbalance() {! : float extends Account. deposit(amount : float) SavingsAccount is! } All methods! from withdraw(amount : float) : boolean a subtype of Account are transfer(amount : float, Account. Account inherited (copied to is a supertype of public interface InterestCheckingAccount! CheckingAccount) monthlyadjustment() extends CheckingAccount, SavingsAccount SavingsAccount. {!! }! «interface» CheckingAccount getfee() : float «interface» SavingsAccount getinterestrate() : float If we know we have a CheckingAccount, addiponal methods are available. «interface» InterestCheckingAccount MulPple interface extension toad 20

21 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: If today is the last day of the month:! For each acct in allaccounts:! acct.monthlyadjustment();!! See the DogWalker example toad 21

22 One implementation: Just use interface inheritance «interface» Account getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() «interface» CheckingAccount getfee() : float «interface» SavingsAccount getinterestrate() : float CheckingAccountImpl «interface» InterestCheckingAccount SavingsAccountImpl InterestCheckingAccountImpl toad 22

23 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» CheckingAccount getfee() : float «interface» Account getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() # balance : float monthlyadjustment() getfee() : float AbstractAccount + getbalance() : float + deposit(amount : float) + withdraw(amount : float) : boolean + transfer(amount : float, + monthlyadjustment() CheckingAccountImpl toad 23

24 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» CheckingAccount getfee() : float an abstract class is missing the implemenpon of one «interface» Account getbalance() : float deposit(amount or more methods : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() protected elements are visible in subclasses an abstract method is leu to be implemented in a subclass no need to define getbalance() the code is inherited from AbstractAccount # balance : float CheckingAccountImpl monthlyadjustment() getfee() : float toad 24 AbstractAccount + getbalance() : float + deposit(amount : float) + withdraw(amount : float) : boolean + transfer(amount : float, + monthlyadjustment()

25 Inheritance vs. subtyping Inheritance A class reuses code from a superclass class A extends B Inheritance is for code reuse Write code once and only once Code from superclass implicitly available in subclass Subtyping A class implements a (Java) interface class A implements I A class implements the (implicit) interface of another class class A extends B : both subtyping and inheritance Subtyping is for polymorphism Accessing objects the same way, but getting different behavior Subtype is substitutable for supertype toad 25

26 Challenge: Is inheritance necessary? Can we get the same amount of code reuse using only interfaces? «interface» Account getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() «interface» CheckingAccount getfee() : float «interface» SavingsAccount getinterestrate() : float «interface» InterestCheckingAccount toad 26

27 Reuse via code wrappers «interface» Account getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() getfee() : float «interface» CheckingAccount public class CheckingAccountImpl! implements CheckingAccount {! BasicAccountImpl basicacct = new( );! public float getbalance() {! return basicacct.getbalance();! }! //! CheckingAccountImpl monthlyadjustment() { } getfee() : float { } getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, CheckingAccountImpl depends on BasicAccountImpl balance : float BasicAccountImpl getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, toad 27

28 Reuse via code wrappers, version 2: Delegation «interface» Account getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() requires two- way dependence BasicAccountImpl account adjustment «interface» Adjustment balance : float doadjust() getbalance() : float deposit(amount : float) withdraw(amount : float) : boolean transfer(amount : float, monthlyadjustment() SavingsAccountAdjustment doadjust() adjustment!.doadjust()! float bal = account.getbalance();! float interest = bal * interestrate;! account.deposit(interest);! toad 28

29 Inheritance vs. delegation Delegation can be cleaner than inheritance Reused code in a separate object Interfaces between objects Inheritance has less boilerplate code No forwarding functions, recursive dependencies toad 29