Applied Design Patterns with Java
Creational :: Factory Method (107) {C ch 4}
Implementation
Consider the following issues when applying the Factory Method
pattern:
- Two
major varieties. The two main variations of the Factory Method
pattern are (1) the case when the Creator class is an abstract class and does not provide an implementation for
the Factory Method it declares, and (2) the case when the Creator is a concrete class and provides a default
implementation for the factory method. It's also possible to have an abstract class that defines a default implementation,
but this is less common. The first case requires subclasses to define an implementation, because there's no reasonable
default. It gets around the dilemma of having to instantiate unforeseeable classes. In the second case, the concrete
Creator uses the Factory Method primarily for flexibility. It's following a rule that says, "Create objects in a separate operation so that subclasses can
override the way they're created." This rule
ensures that designers of subclasses can change the class of objects their parent class instantiates if necessary.
- Parameterized factory methods. Another variation on the pattern lets the Factory
Method create multiple kinds of products. The Factory Method
takes a parameter that identifies the kind of object to create. All objects the Factory Method creates
will share the Product interface.
- Language-specific variants and issues. Different languages lend themselves to other interesting variations and
caveats. An even more flexible approach akin to parameterized Factory
Methods is to store the class to be created as
a class variable of Application, avoiding subclassing Application to vary the product. Factory Methods
in C++ are always virtual functions and are often pure virtual. Do not call Factory Methods in the
Creator's constructor—the Factory Method in the ConcreteCreator won't be available yet. Avoid this by being
careful to access products solely through accessor operations that create the product on demand. Instead of creating
the concrete product in the constructor, the constructor merely initializes it to 0. The accessor returns the product.
But first it checks to make sure the product exists, and if it doesn't, the accessor creates it. This technique
is sometimes called lazy initialization.
- Using
templates to avoid subclassing. Another potential problem
with Factory Methods is that they might force subclassing just to create the appropriate Product objects.
Another way to get around this in C++ is to provide a template subclass of Creator that's parameterized by the
Product class. This option is not available in Java.
- Naming conventions. It's good practice to use naming conventions that make it clear you're using factory methods.
Related Patterns
Abstract Factory (87) is often implemented
with Factory Methods. The Motivation example in the Abstract
Factory pattern illustrates Factory Method
as well.
Factory Methods are usually called within Template
Methods (325). In the document example above, NewDocument is a Template Method.
Prototypes
(117) don't require subclassing Creator. However,
they often require an Initialize operation on the Product class. Creator uses Initialize to initialize the object.
Factory Method doesn't require such an
operation.
Catalog Creational Prev Next