Java Reference
In-Depth Information
input queue overflows and the machines signals an alarm. Figure 6.5 shows a design that
provides for testing classes.
Figure 6.5. In this factoring, subclasses of
MachineController
exist for various types
of machines and for various types of controllers.
Introducing a
TestController
class turns out to force you to create three new classes, as
test controllers for star presses and shell assemblers implement
getQueueMax()
differently.
This is a problem because you'd like to be able to add new classes individually. The problem
arises because the hierarchy is factored according to two principles: Each machine needs its
own controller, and different types of controllers are used for normal operation and for
testing. You really need a class for every combination of machine type and controller type—a
maintenance nightmare. You can solve the problem by separating the
MachineController
abstraction from its implementation.
To refactor a hierarchy with an abstract class at its top into a bridge, do the following.
1. Move the abstract operations in the superclass into an interface.
2. Define implementation classes that provide different implementations of the interface.
3. Redefine the remaining operations in the abstract class as operations on an instance of
the new interface.
