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 : 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.We must put “abstract” in front of each method that’s not implemented. 2.One can be defined at the top of a file before the class. 3.A class can implement more than one interface. 4.A class cannot both implement an interface and also extend a class.

Last 2 “Forms of Inheritance” Again: Textbook, pp : five forms… –Specification, Specialization, Extension, Limitation, and Combination Limitation –A subclass removes or blocks a behavior defined in the super- class –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 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 – 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 object- reference ref defined by: Interface or Superclass (perhaps abstract superclass) –Examples: PlayableItem p; // abstract class TimePiece t; // interface public void syncTimeWith(TimePiece t) {…} ArrayList 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