Abstract Factory
Consequences
The Abstract Factory pattern has the following benefits and liabilities:
- It isolates concrete classes.
The Abstract Factory pattern helps you control the classes of objects
that an application creates. Because a factory encapsulates the
responsibility and the process of creating product objects, it
isolates clients from implementation classes. Clients manipulate
instances through their abstract interfaces. Product class names are
isolated in the implementation of the concrete factory; they do not
appear in client code.
- It makes exchanging product families easy.
The class of a concrete factory appears only once in an
application---that is, where it's instantiated. This makes it easy to
change the concrete factory an application uses. It can use
different product configurations simply by changing the concrete
factory. Because an abstract factory creates a complete family of
products, the whole product family changes at once. In our user
interface example, we can switch from Motif widgets to Presentation
Manager widgets simply by switching the corresponding factory objects
and recreating the interface.
- It promotes consistency among products.
When product objects in a family are designed to work together, it's
important that an application use objects from only one family at a
time. AbstractFactory
makes this easy to enforce.
- Supporting new kinds of products is difficult.
Extending abstract factories to produce new kinds of Products isn't
easy. That's because the
AbstractFactory
interface fixes the set of
products that can be created. Supporting new kinds of products
requires extending the factory interface, which involves changing the
AbstractFactory
class and all of its subclasses. We discuss one solution
to this problem in the Implementation
section.