|
|
|
|
Sponsored Link •
|
Summary
In this installment of my Design Techniques column, I analyze the flexibility and performance implications of inheritance and composition, and I give guidelines on the appropriate use of each.
One of the fundamental activities of any software system design is establishing relationships between classes. Two fundamental ways to relate classes are inheritance and composition. Although the compiler and Java virtual machine (JVM) will do a lot of work for you when you use inheritance, you can also get at the functionality of inheritance when you use composition. This article will compare these two approaches to relating classes and will provide guidelines on their use.
First, some background on the meaning of inheritance and composition.
About inheritance
In this article, I'll be talking about single inheritance through class
extension, as in:
class Fruit {
//...
}
class Apple extends Fruit {
//...
}
In this simple example, class Apple is related to class
Fruit by inheritance, because Apple extends
Fruit. In this example, Fruit is the
superclass and Apple is the subclass.
I won't be talking about multiple inheritance of interfaces through interface extension. That topic I'll save for next month's Design Techniques article, which will be focused on designing with interfaces.
Here's a UML diagram showing the inheritance relationship between
Apple and Fruit:
Figure 1. The inheritance relationship |
About composition
By composition, I simply mean using instance variables that are
references to other objects. For example:
class Fruit {
//...
}
class Apple {
private Fruit fruit = new Fruit();
//...
}
In the example above, class Apple is related to class
Fruit by composition, because Apple has an
instance variable that holds a reference to a Fruit
object. In this example, Apple is what I will call the
front-end class and Fruit is what I will call the
back-end class. In a composition relationship, the front-end
class holds a reference in one of its instance variables to a back-end
class.
The UML diagram showing the composition relationship has a darkened diamond, as in:
Figure 2. The composition relationship |
Dynamic binding, polymorphism, and change
When you establish an inheritance relationship between two classes, you
get to take advantage of dynamic binding and polymorphism.
Dynamic binding means the JVM will decide at runtime which method
implementation to invoke based on the class of the object. Polymorphism
means you can use a variable of a superclass type to hold a reference
to an object whose class is the superclass or any of its subclasses.
One of the prime benefits of dynamic binding and polymorphism is that
they can help make code easier to change. If you have a fragment of
code that uses a variable of a superclass type, such as
Fruit, you could later create a brand new subclass, such
as Banana, and the old code fragment will work without
change with instances of the new subclass. If Banana
overrides any of Fruit's methods that are invoked by the
code fragment, dynamic binding will ensure that Banana's
implementation of those methods gets executed. This will be true even
though class Banana didn't exist when the code fragment
was written and compiled.
Thus, inheritance helps make code easier to change if the needed change involves adding a new subclass. This, however, is not the only kind of change you may need to make.
Changing the superclass interface
In an inheritance relationship, superclasses are often said to be
"fragile," because one little change to a superclass can ripple out and
require changes in many other places in the application's code. To be
more specific, what is actually fragile about a superclass is its
interface. If the superclass is well-designed, with a clean separation
of interface and implementation in the object-oriented style, any
changes to the superclass's implementation shouldn't ripple at all.
Changes to the superclass's interface, however, can ripple out and
break any code that uses the superclass or any of its subclasses.
What's more, a change in the superclass interface can break the code
that defines any of its subclasses.
For example, if you change the return type of a public method in class
Fruit (a part of Fruit's interface), you can
break the code that invokes that method on any reference of type
Fruit or any subclass of Fruit. In addition,
you break the code that defines any subclass of Fruit that
overrides the method. Such subclasses won't compile until you go and
change the return value of the overridden method to match the changed
method in superclass Fruit.
Inheritance is also sometimes said to provide "weak encapsulation,"
because if you have code that directly uses a subclass, such as
Apple, that code can be broken by changes to a superclass,
such as Fruit. One of the ways to look at inheritance is
that it allows subclass code to reuse superclass code. For
example, if Apple doesn't override a method defined in its
superclass Fruit, Apple is in a sense reusing
Fruit's implementation of the method. But
Apple only "weakly encapsulates" the Fruit
code it is reusing, because changes to Fruit's interface
can break code that directly uses Apple.
The composition alternative
Given that the inheritance relationship makes it hard to change the
interface of a superclass, it is worth looking at an alternative
approach provided by composition. It turns out that when your goal is
code reuse, composition provides an approach that yields
easier-to-change code.
Code reuse via inheritance
For an illustration of how inheritance compares to composition in the
code reuse department, consider this very simple example:
class Fruit {
// Return int number of pieces of peel that
// resulted from the peeling activity.
public int peel() {
System.out.println("Peeling is appealing.");
return 1;
}
}
class Apple extends Fruit {
}
class Example1 {
public static void main(String[] args) {
Apple apple = new Apple();
int pieces = apple.peel();
}
}
When you run the Example1 application, it will print out
"Peeling is appealing.", because Apple
inherits (reuses) Fruit's implementation of
peel(). If at some point in the future, however, you wish
to change the return value of peel() to type
Peel, you will break the code for Example1.
Your change to Fruit breaks Example1's code
even though Example1 uses Apple directly and
never explicitly mentions Fruit.
Here's what that would look like:
class Peel {
private int peelCount;
public Peel(int peelCount) {
this.peelCount = peelCount;
}
public int getPeelCount() {
return peelCount;
}
//...
}
class Fruit {
// Return a Peel object that
// results from the peeling activity.
public Peel peel() {
System.out.println("Peeling is appealing.");
return new Peel(1);
}
}
// Apple still compiles and works fine
class Apple extends Fruit {
}
// This old implementation of Example1
// is broken and won't compile.
class Example1 {
public static void main(String[] args) {
Apple apple = new Apple();
int pieces = apple.peel();
}
}
Code reuse via composition
Composition provides an alternative way for Apple to reuse
Fruit's implementation of peel(). Instead of
extending Fruit, Apple can hold a reference
to a Fruit instance and define its own peel()
method that simply invokes peel() on the
Fruit. Here's the code:
class Fruit {
// Return int number of pieces of peel that
// resulted from the peeling activity.
public int peel() {
System.out.println("Peeling is appealing.");
return 1;
}
}
class Apple {
private Fruit fruit = new Fruit();
public int peel() {
return fruit.peel();
}
}
class Example2 {
public static void main(String[] args) {
Apple apple = new Apple();
int pieces = apple.peel();
}
}
In the composition approach, the subclass becomes the "front-end class," and the superclass becomes the "back-end class." With inheritance, a subclass automatically inherits an implemenation of any non-private superclass method that it doesn't override. With composition, by contrast, the front-end class must explicitly invoke a corresponding method in the back-end class from its own implementation of the method. This explicit call is sometimes called "forwarding" or "delegating" the method invocation to the back-end object.
The composition approach to code reuse provides stronger encapsulation
than inheritance, because a change to a back-end class needn't break
any code that relies only on the front-end class. For example, changing
the return type of Fruit's peel() method from
the previous example doesn't force a change in Apple's
interface and therefore needn't break Example2's code.
Here's how the changed code would look:
class Peel {
private int peelCount;
public Peel(int peelCount) {
this.peelCount = peelCount;
}
public int getPeelCount() {
return peelCount;
}
//...
}
class Fruit {
// Return int number of pieces of peel that
// resulted from the peeling activity.
public Peel peel() {
System.out.println("Peeling is appealing.");
return new Peel(1);
}
}
// Apple must be changed to accomodate
// the change to Fruit
class Apple {
private Fruit fruit = new Fruit();
public int peel() {
Peel peel = fruit.peel();
return peel.getPeelCount();
}
}
// This old implementation of Example2
// still works fine.
class Example1 {
public static void main(String[] args) {
Apple apple = new Apple();
int pieces = apple.peel();
}
}
This example illustrates that the ripple effect caused by changing a
back-end class stops (or at least can stop) at the front-end class.
Although Apple's peel() method had to be
updated to accommodate the change to Fruit,
Example2 required no changes.
Comparing composition and inheritance
So how exactly do composition and inheritance compare? Here are several
points of comparison:
Choosing between composition and inheritance
So how do all these comparisons between composition and inheritance
help you in your designs? Here are a few guidelines that reflect how I
tend to select between composition and inheritance.
Make sure inheritance models the is-a
relationship
My main guiding philosophy is that inheritance should be used only when
a subclass is-a superclass. In the example above, an
Apple likely is-a Fruit, so I would be
inclined to use inheritance.
An important question to ask yourself when you think you have an is-a
relationship is whether that is-a relationship will be constant
throughout the lifetime of the application and, with luck, the lifecycle
of the code. For example, you might think that an
Employee is-a Person, when really
Employee represents a role that a Person
plays part of the time. What if the person becomes unemployed? What if
the person is both an Employee and a
Supervisor? Such impermanent is-a relationships should
usually be modelled with composition.
Don't use inheritance just to get code reuse
If all you really want is to reuse code and there is no is-a
relationship in sight, use composition.
Don't use inheritance just to get at polymorphism
If all you really want is polymorphism, but there is no natural is-a
relationship, use composition with interfaces. I'll be talking about
this subject next month.
Next month
In next month's Design Techniques article, I'll talk about
designing with interfaces.
A request for reader participation
I encourage your comments, criticisms, suggestions, flames -- all kinds
of feedback -- about the material presented in this column. If you
disagree with something, or have something to add, please let me know.
You can either participate in a discussion forum devoted to this material or e-mail me directly at bv@artima.com.
About the author
Bill Venners has been writing software professionally for 12 years.
Based in Silicon Valley, he provides software consulting and training
services under the name Artima
Software Company. Over the years he has developed software for the
consumer electronics, education, semiconductor, and life insurance
industries. He has programmed in many languages on many platforms:
assembly language on various microprocessors, C on Unix, C++ on
Windows, Java on the Web. He is author of the book: Inside the Java
Virtual Machine, published by McGraw-Hill.
Reach Bill at bv@artima.com.
This article was first published under the name Composition versus Inheritance: Which One Should You Choose? in JavaWorld, a division of Web Publishing, Inc., October 1998.
|
Sponsored Links
|