Design Patterns Explained

22O Part IV • Putting It All Together: Thinking in Patterns
The context of the
Abstract Factory
the patterns themselves allow me to anticipate possible variation
because I have divided my system into well-behaved classes,
thereby making changes easier to accommodate. Design patterns
help me see where variations may occur, not so much which partic -
ular variations will occur. The well-defined interface I use to contain
my current variations often contains the impacts of new
requirements just as well.
The Abstract Factory is another good example of designing by context.
I may understand early on that a factory object of some sort
will be used to coordinate the instantiation of families (or sets) of
objects. However, there are many different ways to implement it as
follows.
For... The Abstract Factory Says ...
Using derived classes
Using a single object with
switches
Using a configuration file
with switches
Using a configuration file
with RTTI
(runtime-type-identificati
on)
The classic Abstract Factory implementation
requires me to implement a derivation for
each set that I need. This is a little cumbersome
but has the advantage of allowing me
to add new classes without changing any of
my existing classes.
If I am willing to change the Abstract Factory
class as needed, I can simply have one
object that contains all of the rules. While
this doesn't follow the open-closed principle,
it does contain all of my rules in one place
and is not hard to maintain.
This is more flexible than the prior case, but
still requires modifying the code at times.
RTTI includes a way of instantiating objects
based on the name of the object placed in a
string. Implementations of this sort have
great flexibility in that new classes and new
combinations can be added without having
to change any code.