Sunday, November 25, 2012

Abstract Factory Design Pattern

Although they are lots of books and articles about Design Patterns, yet I like to share my point of view about common design patterns with you, and would be happy to have your thoughts or questions on comments. This post introduces GoF Abstract Factory design pattern.

Definition
Provide an interface for creating families of related or dependent objects without specifying their concrete classes. (dofactory)


  • AbstractFactory declares an interface for operations that create abstract products
  • ConcreteFactory implements the operations to create concrete product objects
  • AbstractProduct declares an interface for a type of product object
  • Product defines a product object to be created by the corresponding concrete factory implements the AbstractProduct interface
  • Client uses interfaces declared by AbstractFactory and AbstractProduct classes

Applicability
  • We should use the Abstract Factory design pattern when:
    • The system needs to be independent from the way the products it works with are created.
    • The system is or should be configured to work with multiple families of products.
    • A family of products is designed to work only all together.
    • The creation of a library of products is needed, for which is relevant only the interface, not the implementation, too.

Consequences
  • Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
  • Abstract Factory is a super-factory which creates other factories (Factory of factories).

Downsides
  • Adding new products to the existing factories is difficult, because the Abstract Factory interface uses a fixed set of products that can be created. That is why adding a new product would mean extending the factory interface, which involves changes in the AbstractFactory class and all its subclasses. 

Sample Code 

Related Patterns
  • Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used profitably. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects, Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
  • Abstract Factory, Builder, and Prototype define a factory object that’s responsible for knowing and creating the class of product objects, and make it a parameter of the system. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object (aka prototype) building a product by copying a prototype object.
  • Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype.

References
http://www.dofactory.com/Patterns/PatternAbstract.aspx
http://sourcemaking.com/design_patterns/abstract_factory
http://www.oodesign.com/prototype-pattern.html
http://java.dzone.com/articles/design-patterns-abstract-factory

Further readings
http://en.wikipedia.org/wiki/Abstract_factory_pattern
http://www.avajava.com/tutorials/lessons/abstract-factory-pattern.html
http://www.nileshgule.com/2012/03/abstract-factory-design-pattern.html

No comments :

Post a Comment