Sei sulla pagina 1di 5

Reminder: Inheritance is for

CS2110: SW Development Methods Inheritance in OO and in Java Part 2:

Topics: Forms of inheritance Interfaces in Java

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

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

But most people talk about it this way:

inheritance of interface vs. inheritance of implementation

Models an IS-A relationship Two of the textbook's forms are this:

Specialization: override and implement Extension: add new behavior

Inheritance of Interface
In general in OO, interface refers to what operations can be performed on an object
More general use than Javas keyword interface Interface defined by class public methods

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

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

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

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

But Other things support clock-like activities: get and set time
CellPhone: not IS-A Clock Computer: not IS-A Clock

Which are true of Java interfaces?

1. 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


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




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!

Note this is Java-specific terminology! Most languages just call this inheritance (of 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 package: Closeable, Serializable, Flushable In java.util: Formattable, Collection, List
More on the last two later in the course!

Our Media Player Example

How to Choose: Interface vs. Abstract Class

Use an abstract class when:
There are fields that all subclasses will need At least one method can be given an implementation that some subclasses can inherit (and not override)

Better to use an interface when:

A small number of methods define a role many different kinds of objects can play When the role may be mixed-in with other roles (interfaces) and/or with inheritance

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

Important Principle: Abstraction

Inheritance is an example of the principle of abstraction

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

You now see how polymorphism supports this Now, two ideas about what makes a good design
Abstraction; Hiding Design Decisions

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

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)

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

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)

Result: better software design (Seems vague? Too abstract? Don't worry. You'll see more later!)

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

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

Useful in designing class libraries (we'll see later in Collections)

Hiding exactly how that abstraction is implemented (i.e. its real class) from the code that uses it

Prefer interfaces!
Can mix in several. (Can only extend one class.) Not hierarchical.

Leads to more flexible, modifiable, reusable designs