Design Patterns Explained

224 Part IV • Putting It All Together: Thinking in Patterns
Containing
variation in the
Facade pattern
Not just about
containing variation
The Facade typically does not contain variation. However, I have
seen many cases where a Facade was used to work with a particular
subsystem. Then, when another subsystem came along, a Facade
for the new subsystem was built with the same interface. This new
class was a combination Facade and Adapter in that the primary
motivation was simplification, but now had the added constraint of
being the same as the one used before so none of the client objects
would need to change. Using a Facade this way hides variations in
the subsystems being used.
Patterns are not just about containing variation, however. They also
identify relationships between variations. I will show more about
this in the next section of this book. Referring to the Bridge pattern
again, note that the pattern not only defines and contains the varia -
tions in the abstraction and implementation, but also defines the
relationship between the two variations.
Summary
In this chapter In this chapter, I have shown how patterns illustrate two powerful
design strategies:
• Design from context
• Contain variations in classes
These strategies allow us to defer decisions until we can see the
ramifications of these decisions. Looking at the context from which
we are designing gives us better designs.
By containing variation, I can accommodate future variations that
may arise but would not be accommodated when I do not try to
make my designs more general-purpose. This is critical for those
projects that do not have all of the resources you would like to have
(in other words, all projects). By containing variation appropriately,
I can implement only those features I need without sacrificing