"Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
This pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying implementation details. A good example of this is if you consider a user interface toolkit that supports multiple look-and-feel standards, such as Motif and Presentation Manager. Instantiating look-and-feel-specific classes throughout your application makes it hard to change the look and feel later on in the products lifecycle.
We can solve this problem by using the Abstract Factory design pattern. We specify an abstract class and have concrete subclasses contain look-and-feel specific code.
Use the abstract factory pattern when:
- a system should be independent of how its products are created, composed, and represented
- a system should be configured with one of multiple families of products
- a family of related product objects is designed to be used together, and you need to enforce this constraint
<ul> <li><strong></strong>Declares an interface for operations that create abstract product objects.</li> </ul> </li> <li><strong>ConcreteFactory</strong> <ul> <li><strong></strong>implements the operations to create concrete product objects.</li> </ul> </li> <li><strong>AbstractProduct</strong> <ul> <li><strong></strong>declares an interface for a type of product object.</li> </ul> </li> <li><strong>ConcreteProduct</strong> <ul> <li><strong></strong>defines a product object to be created by the corresponding concrete factory</li> <li>implements the AbstractProduct interface</li> </ul> </li> <li><strong>Client</strong> <ul> <li><strong></strong>uses only interfaces declared by AbstractFactory and AbstractProduct classes.</li> </ul> </li>
To be added.