Provide an interface for creating families of related or dependent objects, w/o specifiying their concrete classes.
Kit
To enable easy changing of the look, feel of an application. Also clients should stay independent of the prevailing look and feel. WidgetFactory
is the topmost abstract class. There will be concrete subclass of WidgetFactory
for each look-and-feel standard. ex. MotifWidgetFactory
, which returns a Motif scroll bar. PMWidgetFactory
, returning a scroll bar for Presentaion Manager.
Clients have no idea of WidgetFactory
interface. Only use instance of the concrete subclasses, but adhere to interface defined by the abstract class WidgetFactory
.
AbstratFactory
and AbstractProduct
ConcreteFactory
class is created at run-time. Of course. its a factory. Creates one kind of product. If client wants different product, use another factory.AbstractFactory
defers creation of product objects to its ConcreteFactory
subclass.Benefits & Liabilities
1. It isolates concrete classes. Product class names are isolated in the implementation of the concrete factory. not in client code.
2. It makes exchangin product families easy. The class of concrete factory appears only once in an application, where it's instantiated. So no duplicate code change when changin concrete factory to use.
3. Promotes consistency among products. AbstractFactory
enforcement.
4. Supporting new kinds of products is difficult. Fixed interface. What if new product requires extended interface? hard. Lots of code to change. But one possible solution in Implementaion section.
Some useful techniques for implementing the Abstrat Factory pattern.
1. Factories as singletons.
2. Creating the products. See Factory Method pattern for each product. This overrides I think the constructor()
for product classes?
If many product families are possible, refer to Prototype pattern. A javascript
like pattern I think.
Pure Prototype apporach
Concrete factory has protype of a product. Factory clones the prototype, and creates the product. Eliminates the need for a new concrete factory calss for each new product family.
Prototype variant
Possible in languages that treat classes as first-class objects. Define a new factory by initializing an instance of concrete factory with classes of products, not by subclassing. This approach takes advantage of language characteristics, whereas the pure Prototype-based approach is language-independent.
3. Defining extensible factories. AbstractFactory
usually defines a different operation for each kind of product it can produce. The kinds of products are encoded in the operation signatures. Adding a new kind of product requires changin the AbstractFactory interface and all the classes that depend on it.
AbstractFactory
would only need a single make()
method with a parmeter indicating the kind of object to create. This is the technique used in the Prototype- and the class-based abstract factories discuessed earlier. in C++ in books.
if you want dynamic language example, there is also SmallTalk example. But you have to know the C++ example first to understand.
Old cases.. Interviews? ET++?
implement using Factory Method, or Prototype
A concrete factory is often a Singleton.