lecture12-MoreInheritance-Patterns

Download Report

Transcript lecture12-MoreInheritance-Patterns

Lot More Inheritance and
Intro to Design Patterns
Computer Science and Engineering  College of Engineering  The Ohio State University
Lecture 12
Recall: Interface Inheritance
Computer Science and Engineering  The Ohio State University
void select (Person p) {
//declared type of p is:
//dynamic type of p is:
Person
SmartPerson
Every student
is a person
Student
OsuStudent
extends
implements
person
student
Recall: Behavioral Subtyping
Computer Science and Engineering  The Ohio State University
 A Student can do everything a Person can do
 Everywhere a Person is expected, a Student
can be used instead
void select (Person p) {
if (p.getAge() > 18) {
p.summons(Date trialDate);
... etc ...
 Every method promised in Person interface:
 Is implemented in SmartPerson class
 Is promised in Student interface
 Is implemented in OsuStudent class
 Are two separate implementations of getAge
really necessary (or even a good idea)?
Generics and Inheritance
Computer Science and Engineering  The Ohio State University
 Is a Stack<Student> a
Stack<Person>?
 Can a Stack<Student> do everything a
Stack<Person> can do?
 Can code expecting a Stack<Person> be
given a Stack<Student> instead?
 Java’s choice:
 No!
 For a generic class G, there is no implicit
subtyping relationship between G<A> and
G<B>
 Neither covariance nor contravariance
Implementation Inheritance
Computer Science and Engineering  The Ohio State University
 Keyword: extends
public class OsuStudent extends SmartPerson {
. . .
}
 OsuStudent has SmartPerson’s members
(fields + methods, including implementation)
 If omitted, java.lang.Object is implicit
extends
Person
SmartPerson
implements
Student
OsuStudent
Class Hierarchy
Computer Science and Engineering  The Ohio State University
 Inheritance is transitive
 Every class inherits from
Object
java.lang.Object
DnaCreature
Parent
Base
Super
Child
Derived
Sub
extends
SmartPerson
OsuStudent
CseMajor
OsuFaculty
CseGrad
java.lang.Object
Computer Science and Engineering  The Ohio State University
 The root of all class hierarchies
 This is a class called “Object”
 There is also a class in java.lang called “Class”!
 Provides several useful methods
 getClass()
 Returns Class of the object instance
 String toString()
 Returns String representing object value
 boolean equals(Object)
 Returns true iff argument is equal to object
 int hashCode()
 Returns an int “hash value” for object
 Object clone()
 Creates and returns a copy (here be dragons…)
The getClass() Method
Computer Science and Engineering  The Ohio State University
 Returns an instance of java.lang.Class
 Generic class: Class<T>
 String getName()
 Name of the class as a string, eg “CseMajor”
 Think of it as representing the object’s class
Student s1 = new OsuStudent();
Student s2 = new CseMajor();
System.out.println(s1.getClass().getName());
System.out.println(s2.getClass().getName());
if (s1.getClass() == s2.getClass()) { . . .
 Of course (?) java.lang.Class extends Object!
 Try not to think about this too hard
Good Practice: Core Methods
Computer Science and Engineering  The Ohio State University
 Always override toString()
 Default implementation gives class name + @ + a
meaningless hex number
 eg “BankAccount@3d4606bf”
 Always override equals()
 Default implementation checks object references
for equality
Pencil p1 = new LeadedPencil();
Pencil p2 = new LeadedPencil();
assert(!p1.equals(p2));
 Always override hashCode()
 Default implementation is memory address
 What is a hashCode? Stay tuned...
 clone(): To override or not?
 Things get very dicey here
Class and Interface Hierarchies
Computer Science and Engineering  The Ohio State University
extends
implements
Object
SmartPerson
OsuStudent
CseMajor
Voter
OsuFaculty
Salaried
CseGrad
Voter v
v = new
v = new
v = new
= new SmartPerson();
OsuStudent();
CseGrad();
OsuFaculty();
Mechanics
Computer Science and Engineering  The Ohio State University
A class extends exactly one other class
 “single inheritance” (cf C++)
 A subclass has all the members of its superclass!
 Not the private members
 Not the constructors (ie just fields and methods)
 Subclass can add new members (hence “extends”)
 New fields and new methods
 Defines its own constructor(s)
 Subclass can modify inherited methods
 Changes behavior
 “overriding”

Example: Code
Computer Science and Engineering  The Ohio State University
class SmartPerson {
private String name;
class OsuStudent extends
SmartPerson {
private int ID;
SmartPerson () {
this.name = “Baby Doe”;
}
OsuStudent () {
this.ID = 0;
}
SmartPerson (String name) {
this.name = name;
}
OsuStudent (String name, int
ID) {
super(name);
this.ID = ID;
}
void rename (String name) {
this.name = name;
}
boolean winsTicketLottery () {
return (this.ID % 2 == 0);
}
String getName () {
return this.name;
}
String toString () {
return this.getName() +
“ [“ + this.ID + “]”;
}
}
}
Example: Graphical View
Computer Science and Engineering  The Ohio State University
ID
name
name
SmartPerson()
SmartPerson()
rename()
rename()
getName()
getName()
SmartPerson p = new SmartPerson()
OsuStudent()
winsTicket…()
OsuStudent s = new OsuStudent()
toString()
Constructing New Instances
Computer Science and Engineering  The Ohio State University
 Members of OsuStudent:
 its own: ID, winsTicketLottery(), toString()
 its parent’s: rename(), getName()
 its parent’s parent’s: see java.lang.Object
 eg clone(), equals(), hashCode(),…
 When a new instance is created:
 First, the parent’s constructor is invoked
 Can be done explicitly with super()
 Otherwise, parent’s default constructor is called
 Next, any initialization blocks are executed
 Finally, the child’s constructor is executed
Overriding Methods
Computer Science and Engineering  The Ohio State University


Overriding: a subclass declares a method that is already
present in its superclass
Note: signatures must match (otherwise it is just
overloading)
class SmartPerson {
String toString() {
return this.getName();
}
}
class OsuStudent extends SmartPerson {
String toString() {
return this.getName() + “ [“ + this.ID + “]”;
}
}

Question: which method is called?
SmartPerson p = new OsuStudent();
System.out.println(p.toString());

Declared type: SmartPerson, dynamic type: OsuStudent
Polymorphism
Computer Science and Engineering  The Ohio State University
Answer: The dynamic type determines which method is
called
SmartPerson p = new OsuSudent();
p.toString() //calls OsuStudent version
 Informal model:
 Method invocation is a run-time message to the object
 That (run-time) object receives the request, performs
the action, and returns the result
 Goal: we get the right behavior regardless of actual (ie
run-time, ie dynamic) type

Person[] csePeople = … //students & faculty in CSE
for (int i = 0; i < csePeople[].length; i++) {
csePeople[i].toString();
}

Note: this applies to methods only, not fields
 Fields can not be overridden, only hidden
Good Practice: @Override
Computer Science and Engineering  The Ohio State University
 Use @Override annotation with all methods
intended to override a method in a
superclass
class OsuStudent extends SmartPerson {
@Override
String getName() {
. . .
}
}
 Compiler complains if there is no matching
method in superclass
 Prevents accidental overloading if a mistake is
made in the signature
 Beware: Differences between Java 5 & 6
Hook methods
Computer Science and Engineering  The Ohio State University


Dynamic type of this controls which method executes
Hook method: Called internally, intended to be overridden
class Course {
void enroll(Student s) {
if (checkEligibility(s)) { … }
}
boolean checkEligibility(Student s) {
//determines whether s has prereqs for this course
}
}
class Tutorial extends Course {
boolean checkEligibility(Student s) {
//determines whether s has paid
}
}

Yo-yo problem:

Must trace up & down class hierarchy to understand code
Course workshop = new Tutorial();
workshop.enroll(s);
Hook and Template Pattern
Computer Science and Engineering  The Ohio State University
 Recall pattern:
 Base class contains both template and hook
methods
 Template method calls this.hook method
 Hook methods are overridden in derived classes
 Template method is not
 To support this pattern:
 Template method is declared final
 Hook methods are declared abstract
 So base class declared abstract too
 Hook methods are declared protected
 See divide-and-conquer example
 solve() is the template method
Hook and Template, and
Abstract Classes
Computer Science and Engineering  The Ohio State University
public abstract class Course {
public final void enroll(Student s) {
if (checkEligibility(s)) { … }
}
protected abstract boolean
checkEligibility(Student s);
}
public class Tutorial extends Course {
@Override
protected boolean
checkEligibility(Student s) {
//determines whether s has paid
}
}
Protected
Computer Science and Engineering  The Ohio State University
 We have seen three levels of visibility
 private: concrete representation
 default (ie package): trusted and co-located
 public: abstract interface to all clients
 Writing a subclass often requires:
 More access than a generic client
 Less access than whole concrete representation
 Solution: new visibility level
 Keyword: protected
 Protected members are inherited but are not part
of the public interface to generic clients
 Warning: anyone can extend your class and then
has access to protected members
Good Practice: Limited Use
Computer Science and Engineering  The Ohio State University
 Getting it right is hard
 Unless you have an explicit need for an open (ie
extendable) class hierarchy, prevent others from
extending your classes
 Keyword final prevents extensions
public final class Faculty {
. . .
}
public class Administrator extends Faculty {
. . . //compiler complains
}
 If you do have a specific need to allow extensions, design
for it carefully


Use protected diligently and carefully (it’s a huge increase
in visibility over private or even over package!)
Chances are, it will still be broken
Summary
Computer Science and Engineering  The Ohio State University
 Implementation (class) inheritance
 Declaration syntax: extends just like interfaces
 Vocabulary: super/sub, base/derived, parent/child
 Class and interface hierarchies
 Constructing new instances
 Overriding and polymorphism
 Signature must match exactly (use @Override)
 Dynamic type controls implementation
 Hook methods: dynamic type of this
 Protected visibility
 Limiting extension: final
Supplemental Reading
Computer Science and Engineering  The Ohio State University
 Bloch’s “Effective Java”, chapter 3
 See Safari Books Online link
 Warning: favors instanceOf over getClass
 Better for behavioral subtyping
 Worse for creating an equivalence relation
 IBM developerWorks paper
 “Java Theory and practice: Hashing it out”
 http://www.ibm.com/developerworks/java
/library/j-jtp05273.html
 Various blogs (all slightly broken)
 http://www.geocities.com/technofundo/te