Design Patterns Explained

146 Part III Design Patterns
From an object
perspective
I said at the beginning of this chapter that my confusion over the
Bridge pattern was due to my misunderstanding of the term
“implementation.” I thought that implementation referred to how I
implemented a particular abstraction.
The Bridge pattern let me see that viewing the implementation as
something outside of my objects, something that is used by the
objects, gives me much greater freedom by hiding the variations in
implementation from my calling program. By designing my objects
this way, I also noticed how I was containing variations in separate
class hierarchies. The hierarchy on the left side of Figure 9-13 contains
the variations in my abstractions. The hierarchy on the right
side of Figure 9-13 contains the variations in how I will implement
those abstractions. This is consistent with the new paradigm for creating
objects (using commonality/variability analysis) that I mentioned
earlier.
It is easiest to visualize this when you remember that there are only
three objects to deal with at any one time, even though there are
several classes (see Figure 9-14).
Figure 9-14 There are only three objects at a time.