Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
http://en.wikipedia.org/wiki/Abstract_factory_pattern
The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.[1] In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products.[1] This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface
Where Would I Use This Pattern?
The pattern is best utilised when your system has to create multiple families of products or you want to provide a library of products without exposing the implementation details.
Application
GUIFactory: createWindow, createButton
someone has to determine what type of factory the client is dealing with at runtime. As you see above, this is usually done with some type of switch statement.
http://sourcemaking.com/design_patterns/abstract_factory
Read full article from Design Patterns Uncovered: The Abstract Factory Pattern | Javalobby
http://en.wikipedia.org/wiki/Abstract_factory_pattern
The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.[1] In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products.[1] This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface
The AbstractFactory defines the interface that all of the concrete factories will need to implement in order to product Products. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface here, creating two seperate families of product. Meanwhile,AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts.
The Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn't know anything about the implementations. The actual implementation of AbstractFactory that theClient uses is determined at runtime.
Where Would I Use This Pattern?
The pattern is best utilised when your system has to create multiple families of products or you want to provide a library of products without exposing the implementation details.
Application
GUIFactory: createWindow, createButton
someone has to determine what type of factory the client is dealing with at runtime. As you see above, this is usually done with some type of switch statement.
http://sourcemaking.com/design_patterns/abstract_factory
Read full article from Design Patterns Uncovered: The Abstract Factory Pattern | Javalobby
