1. Overview
Inheritance and composition — along with abstraction, encapsulation, and polymorphism — are cornerstones of object-oriented programming (OOP).
In this tutorial, we'll cover the basics of inheritance and composition, and we'll focus strongly on spotting the differences between the two types of relationships.
2. Inheritance's Basics
Inheritance is a powerful yet overused and misused mechanism.
Simply put, with inheritance, a base class (a.k.a. base type) defines the state and behavior common for a given type and lets the subclasses (a.k.a. subtypes) provide specialized versions of that state and behavior.
To have a clear idea on how to work with inheritance, let's create a naive example: a base class Person that defines the common fields and methods for a person, while the subclasses Waitress and Actress provide additional, fine-grained method implementations.
Here's the Person class:
|
1
2
3
4
5
|
public
class
Person {
private
final
String name;
// other fields, standard constructors, getters
}
|
And these are the subclasses:
|
1
2
3
4
5
6
7
8
|
public
class
Waitress
extends
Person {
public
String serveStarter(String starter) {
return
"Serving a "
+ starter;
}
// additional methods/constructors
}
|
|
1
2
3
4
5
6
7
8
|
public
class
Actress
extends
Person {
public
String readScript(String movie) {
return
"Reading the script of "
+ movie;
}
// additional methods/constructors
}
|
In addition, let's create a unit test to verify that instances of the Waitress and Actress classes are also instances of Person, thus showing that the “is-a” condition is met at the type level:
|
1
2
3
4
5
6
7
8
9
10
11
|
public
void
givenWaitressInstance_whenCheckedType_thenIsInstanceOfPerson() {
assertThat(
new
Waitress(
"Mary"
,
"mary@domain.com"
,
22
))
.isInstanceOf(Person.
class
);
}
public
void
givenActressInstance_whenCheckedType_thenIsInstanceOfPerson() {
assertThat(
new
Actress(
"Susan"
,
"susan@domain.com"
,
30
))
.isInstanceOf(Person.
class
);
}
|
It's important to stress here the semantic facet of inheritance. Aside from reusing the implementation of the Person class, we've created a well-defined “is-a” relationship between the base type Person and the subtypes Waitress and Actress. Waitresses and actresses are, effectively, persons.
This may cause us to ask: in which use cases is inheritance the right approach to take?
If subtypes fulfill the “is-a” condition and mainly provide additive functionality further down the classes hierarchy, then inheritance is the way to go.
Of course, method overriding is allowed as long as the overridden methods preserve the base type/subtype substitutability promoted by the Liskov Substitution Principle.
Additionally, we should keep in mind that the subtypes inherit the base type's API, which is some cases may be overkill or merely undesirable.
Otherwise, we should use composition instead.
3. Inheritance in Design Patterns
While the consensus is that we should favor composition over inheritance whenever possible, there are a few typical use cases where inheritance has its place.
3.1. The Layer Supertype Pattern
In this case, we use inheritance to move common code to a base class (the supertype), on a per-layer basis.
Here's a basic implementation of this pattern in the domain layer:
|
1
2
3
4
5
6
|
public
class
Entity {
protected
long
id;
// setters
}
|
|
1
2
3
4
|
public
class
User
extends
Entity {
// additional fields and methods
}
|
We can apply the same approach to the other layers in the system, such as the service and persistence layers.
3.2. The Template Method Pattern
In the template method pattern, we can use a base class to define the invariant parts of an algorithm, and then implement the variant parts in the subclasses:
|
1
2
3
4
5
6
7
8
9
10
11
|
public
abstract
class
ComputerBuilder {
public
final
Computer buildComputer() {
addProcessor();
addMemory();
}
public
abstract
void
addProcessor();
public
abstract
void
addMemory();
}
|
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public
class
StandardComputerBuilder
extends
ComputerBuilder {
public
void
addProcessor() {
// method implementation
}
@Override
public
void
addMemory() {
// method implementation
}
}
|
4. Composition's Basics
The composition is another mechanism provided by OOP for reusing implementation.
In a nutshell, composition allows us to model objects that are made up of other objects, thus defining a “has-a” relationship between them.
Furthermore, the composition is the strongest form of association, which means that the object(s) that compose or are contained by one object are destroyed too when that object is destroyed.
To better understand how composition works, let's suppose that we need to work with objects that represent computers.
A computer is composed of different parts, including the microprocessor, the memory, a sound card and so forth, so we can model both the computer and each of its parts as individual classes.
Here's how a simple implementation of the Computer class might look:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public
class
Computer {
private
Processor processor;
private
Memory memory;
private
SoundCard soundCard;
// standard getters/setters/constructors
public
Optional<SoundCard> getSoundCard() {
return
Optional.ofNullable(soundCard);
}
}
|
The following classes model a microprocessor, the memory, and a sound card (interfaces are omitted for brevity's sake):
|
1
2
3
4
5
6
|
public
class
StandardProcessor
implements
Processor {
private
String model;
// standard getters/setters
}
|
|
1
2
3
4
5
6
7
|
public
class
StandardMemory
implements
Memory {
private
String brand;
private
String size;
// standard constructors, getters, toString
}
|
|
1
2
3
4
5
6
|
public
class
StandardSoundCard
implements
SoundCard {
private
String brand;
// standard constructors, getters, toString
}
|
It's easy to understand the motivations behind pushing composition over inheritance. In every scenario where it's possible to establish a semantically correct “has-a” relationship between a given class and others, the composition is the right choice to make.
In the above example, Computer meets the “has-a” condition with the classes that model its parts.
It's also worth noting that in this case, the containing Computer object has ownership of the contained objects if and only if the objects can't be reused within another Computer object. If they can, we'd be using aggregation, rather than composition, where ownership isn't implied.
5. Composition Without Abstraction
Alternatively, we could've defined the composition relationship by hard-coding the dependencies of the Computer class, instead of declaring them in the constructor:
|
1
2
3
4
5
6
7
8
9
|
public
class
Computer {
private
StandardProcessor processor
=
new
StandardProcessor(
"Intel I3"
);
private
StandardMemory memory
=
new
StandardMemory(
"Kingston"
,
"1TB"
);
// additional fields / methods
}
|
Of course, this would be a rigid, tightly-coupled design, as we'd be making Computer strongly dependent on specific implementations of Processor and Memory.
We wouldn't be taking advantage of the level of abstraction provided by interfaces and dependency injection.
With the initial design based on interfaces, we get a loosely-coupled design, which is also easier to test.
6. Conclusion
In this article, we learned the fundamentals of inheritance and composition in Java, and we explored in depth the differences between the two types of relationships (“is-a” vs. “has-a”).
As always, all the code samples shown in this tutorial are available over on GitHub.
来源：oschina
链接：https://my.oschina.net/ciet/blog/3161917