4.6. When to Use Interfaces
An interface defines a type with an abstract contract. An abstract class also defines a type with an abstract
contract. Which should you use and when?
There are two major differences between interfaces and abstract classes:
Interfaces provide a form of multiple inheritance, because you can implement multiple interfaces. A
class can extend only one other class, even if that class has only abstract methods.•
An abstract class can have a partial implementation, protected parts, static methods, and so on,
whereas interfaces are limited to public constants and public methods with no implementation.•
These differences usually direct the choice of which tool is best to use in a particular implementation. If
multiple inheritance is important or even useful, interfaces are used. However, an abstract class enables you to
provide some or all of the implementation so that it can be inherited easily, rather than by explicit forwarding.
Additionally, an abstract class can control the implementation of certain methods by making them finalfor
example, our SortDouble class in Chapter 3 ensures that sorting is done correctly. However, if you find
yourself writing an abstract class with all abstract methods, you're really writing an interface.
Any major class you expect to be extended, whether abstract or not, should be an implementation of an
interface. Although this approach requires a little more work on your part, it enables a whole category of use
that is otherwise precluded. For example, suppose we had created an Attributed class instead of an
Attributed interface with an AttributedImpl implementation class. In that case, programmers who
wanted to create new classes that extended other existing classes could never use Attributed, since you
can extend only one classthe class AttributedBody could never have been created. Because
Attributed is an interface, programmers have a choice: They can extend AttributedImpl directly and
avoid the forwarding, or, if they cannot extend, they can at least use composition and forwarding to implement
the interface. And if the general implementation provided is incorrect, they can write their own
implementation. You can even provide multiple possible implementations of the interface to prospective
users. Whatever implementation strategy programmers prefer, the objects they create are Attributed.
Exercise 4.1: Rewrite your solution to Exercise 3.6 on page 99 using an interface for EnergySource
instead of an abstract class.
Exercise 4.2: Rewrite your solution to Exercise 3.12 on page 114 using an interface if you didn't write it that
way in the first place.
Exercise 4.3: Should the LinkedList class from previous exercises be an interface? Rewrite it that way
with an implementation class before you decide.
Exercise 4.4: Design a collection class hierarchy using only interfaces.
Exercise 4.5: Think about whether the following types should be represented as interfaces, abstract classes, or
concrete classes: (a) treeNode to represent nodes in an N-ary tree; (b) treeWalker to walk the tree in a
particular order (such as depth-first or breadth-first); (c) Drawable for objects that can be drawn by a
graphics system; (d) Application for programs that can be run from a graphical desktop.
Exercise 4.6: What changes in your assumptions about each of the problems in Exercise 4.5 would make you
change your answers?
There are two ways of constructing a software design: one way is to make it so simple that
there are obviously no deficiencies; the other is to make it so complicated that there are no