Transcript Slides

CS2110: SW Development Methods
Inheritance in OO and in Java
Part 2:
Topics:
• Forms of inheritance
• Interfaces in Java
Reminder: Inheritance is for…
• Inheritance can support us with these
three needs:
– Code reuse
– Domain modeling
– Flexible Design
Forms of Inheritance
• Let’s re-visit why we might choose to use
inheritance again
• Textbook, pp. 52-56:
There are five forms of inheritance
– Specification, Specialization, Extension,
Limitation, and Combination
• But most people talk about it this way:
– inheritance of interface vs. inheritance of
implementation
Inheritance of Implementation
• Some common behaviors are implemented
in the superclass
– Each subclass may override a method,
or implement a few abstract methods
– Superclass specifies what and how
• Models an IS-A relationship
• Two of the textbook’s forms are this:
– Specialization: override and implement
– Extension: add new behavior
Inheritance of Interface
• For a class, interface refers to what
operations can be performed on an object
• We saw polymorphism used to:
– Have “more general” object-references to
instances that are really “more specialized”
– Then, call operations on the object-reference,
knowing that the specialized implementation
in each subclass will be called.
– E.g. list.get(i).play(); // list of Playable
ShapeRef.draw(); // Shape is superclass
Inheritance of Interface (2)
• Could use inheritance just to define a set
of operations that a subclass must
implement
– Without giving any default behaviors /
implementations
• This is the book’s “specification form” of
inheritance
• Vote: Could you use an abstract class to
do this?
PlayableItem for Music Player
• PlayableItem, is really this:
– A type used to refer to “anything that can be
played”
• Type? Object-reference, parameter type, etc.
Clock Example from Book
• “You cannot be considered a Clock unless
you provide behaviors that determine and
set the time -- the two essential behaviors
of all clocks.” (p. 53, slightly edited)
• Implies these operations
– setCurrentTime(Time t);
– Time getCurrentTime();
– Also may imply a time-value is stored or
somehow available
Clock Example from Book (2)
• Let’s contrast the two types of inheritance
• Specialization/Extension
– A DigitalClock IS-A Clock
– An AtomicClock IS-A Clock
• But… Other things support “clock-like”
activities: get and set time
– CellPhone: not IS-A Clock
– Computer: not IS-A Clock
Inheritance of Interface, IS-A
• Hmm. We want to carry out “clock-like”
operations on things that are not really Clocks
(in the IS-A sense)
• But these things do support an interface we’ve
defined
• We use “specification inheritance” for this, but
– Java renames and gives a convenient implementation
of this form of inheritance.
Java calls this an interface.
– In C++: use “pure abstract class”, multiple
inheritance
Which are true of Java interfaces?
1.
2.
3.
4.
We must put “abstract”
in front of each method
that’s not implemented.
One can be defined at
the top of a file before
the class.
A class can implement
more than one
interface.
A class cannot both
implement an interface
and also extend a class.
Last 2 “Forms of Inheritance”
• Again: Textbook, pp. 52-56: five forms…
– Specification, Specialization, Extension, Limitation, and
Combination
• Limitation
– A subclass removes or blocks a behavior defined in the superclass
– Not supported directly in Java, but…
• Collections library: Sometimes a subclass will throw an
UnsupportedOperationException
• Combination
– A superclass/subclass exhibits more than one
– Multiple-inheritance supported in some languages
If you could “do limitation”, do you
think this has a negative impact on the
OO substitutability principle?
1. Yes
2. No
Interface Inheritance in Java
• In Java
– A subclass can only extend one super-class
• Java does not have multiple
implementation-inheritance
– But, it can also “inherit” an interface from
one or many interface definitions
– Java term: a class “implements” an interface
• The class says: I promise to support the
operations listed in this interface!
Clock Example and Interfaces
• Something that can set and display time
supports “TimePiece”:
public interface TimePiece {
public void setCurrentTime(Time t);
public Time getCurrentTime();
} // note how this is like a class definition
• And possible ways it could be used:
– public class CellPhone implements TimePiece {...
– public class WallClock implements TimePiece {…
– public abstract class GenericClock
implements TimePiece {…
– public class WallClock extends GenericClock {…
UML for Clock Example
Interface, Types, Polymorphism
• We can use the interface as a type:
ArrayList<TimePiece> tList = …;
// somehow put objects that implement TimePiece
//
into tList
TimePiece t = tList.get(i);
t.setCurrentTime( new Time(…) );
// Note: can only call methods defined in TimePiece
// BTW, in Java we’d use the Date class
Interfaces in Java
• Widely used and powerful!
• Cleaner / safer than allowing full multiple
inheritance (like C++ does)
– public class CellPhone implements
TimePiece, Ringable {...
– public class WallClock extends GenericClock
implements Ringable {…
• Often have names ending in –able or –ible
– In java.io package: Closeable, Serializable, Flushable
– In java.util: Formattable, Collection, List
• More on the last two later in the course!
Our Media Player Example
Inheritance and Design
• One of three reasons we gave about why inheritance is
used: Flexible design
• We said (earlier):
– Gives us more flexibility at run-time in calling operations on
objects that might be of different types
• Recall we use reference variables to “point to” objects
• You now see how polymorphism supports this
• Now, two ideas about what makes a good design
– Abstraction; Hiding Design Decisions
Important Principle: Abstraction
• Inheritance is an example of the principle of
abstraction
– http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29
• Inheritance of implementation (IS-A)
– You can think of a subclass item as a type of some
more general type of object
– Same state, some common behavior
• Inheritance of interface (e.g. Java interfaces)
– You can think of an object as an instance of
something that can be used or operated on in a
certain defined way
– E.g. it’s comparable, printable, playable, drawable
Hiding Design Decisions
• The “black box” idea is important in
design
– Some “component” X, i.e. part of the system,
is like a black box
– The rest of the system knows how to interact
with it through its interface (“interface” in
general sense)
– We swap in many different components for X
as long as each has the same interface as X
Hiding Design Decisions in OO
• In OO software:
– We reference components by type, I.e. an objectreference ref defined by:
• Interface or Superclass (perhaps abstract superclass)
– Examples:
PlayableItem p; // abstract class
TimePiece t; // interface
public void syncTimeWith(TimePiece t) {…}
ArrayList<PlayableItem> thePlayList;
• What kind of object is the reference really
pointing at?
– The client-code doesn’t have to know.
– But it does know what interface is supported.
Hiding Design Decisions
• A term for hiding design decisions this way is:
information hiding
– But information means more than data here
– It means how things are designed or implemented
• An object-reference to a Java interface or a
superclass is a use of abstraction
• Coding using abstractions makes systems more
flexible, easy to change, easier to re-use parts
– Could rephrase this as “coding to abstractions”
• Result: better software design
• (Seems vague? Too “abstract”? Don’t worry.
You’ll see more later!)
Summary
• Pure inheritance of interface
– Java lets you define an interface (like an
“empty” class, just method stubs, no fields)
– Classes can implement one or many interfaces
• BTW, one interface definition can extend another
one (i.e. add to it)
– When a class implements an interface:
• It promises that it will support those methods
• Other code can operate such objects assuming that
interface exists (e.g. its methods can be called)
Even More Summary
• Some guidelines:
– Abstract classes:
• Use if IS-A applies and you need to define some
(not all) behavior
– combines inheritance of interface and inheritance of
implementation
• Useful in designing class libraries (we’ll see later
in Collections)
– Prefer interfaces!
• Can mix in several. (Can only extend one class.)
Not hierarchical.
Final Bit of Summary
• Inheritance supports good SW design
– We often refer to specific objects using
references to superclasses or interfaces
– By doing this, we are:
• Thinking of the object as a higher-level abstraction
– I.e. only in terms of the superclass or interface
• Hiding exactly how that abstraction is implemented
(i.e. its “real” class) from the code that uses it
– Leads to more flexible, modifiable, reusable
designs