Abstract Factory Pattern
Question:What is the abstract factory pattern?
Answer: A factory pattern in which the factory class is abstract so that its implementation can be given as per requirement.
Answer: A factory pattern in which the factory class is abstract so that its implementation can be given as per requirement.
This pattern provids an interface for creating families of related or dependent objects without specifying their concrete classes.
Given a set of related abstract classes, the Abstract Factory pattern provides a way to create instances of those abstract classes from a matched set of concerte subclases. The "Abstract Factory" pattern provides an abstract class that determines the appropriate concrete class to instantiate to create a set of concrete products that implement a standard interface. The client interacts only with the product interfaces and the Abstract Factory class. The client never knows about the concrete construction classes provided by this pattern. The Abstract Factory pattern is similar to the Factory Method pattern, except it creates families of related objects.
Given a set of related abstract classes, the Abstract Factory pattern provides a way to create instances of those abstract classes from a matched set of concerte subclases. The "Abstract Factory" pattern provides an abstract class that determines the appropriate concrete class to instantiate to create a set of concrete products that implement a standard interface. The client interacts only with the product interfaces and the Abstract Factory class. The client never knows about the concrete construction classes provided by this pattern. The Abstract Factory pattern is similar to the Factory Method pattern, except it creates families of related objects.
Theory behind the Abstract Factory Pattern
The abstract factory pattern is a software design pattern that provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage.
An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a number of products (e.g. createLetter() and createResume()). The system would have any number of derived concrete versions of the DocumentCreator class like FancyDocumentCreator or ModernDocumentCreator, each with a different implementation of createLetter() and createResume() that would create a corresponding object like FancyLetter or ModernResume.
Each of these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the resulting objects would be created from the same DocumentCreator implementation and would share a common theme (they would all be fancy or modern objects). The client would need to know how to handle only the abstract Letter or Resume class, not the specific version that it got from the concrete factory.
A factory is the location or a concrete class in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class. Use of this pattern makes it possible to interchange concrete implementations without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code. Used correctly the "extra work" pays off in the second implementation of the factory.
An example of this would be an abstract factory class DocumentCreator that provides interfaces to create a number of products (e.g. createLetter() and createResume()). The system would have any number of derived concrete versions of the DocumentCreator class like FancyDocumentCreator or ModernDocumentCreator, each with a different implementation of createLetter() and createResume() that would create a corresponding object like FancyLetter or ModernResume.
Each of these products is derived from a simple abstract class like Letter or Resume of which the client is aware. The client code would get an appropriate instance of the DocumentCreator and call its factory methods. Each of the resulting objects would be created from the same DocumentCreator implementation and would share a common theme (they would all be fancy or modern objects). The client would need to know how to handle only the abstract Letter or Resume class, not the specific version that it got from the concrete factory.
A factory is the location or a concrete class in the code at which objects are constructed. The intent in employing the pattern is to insulate the creation of objects from their usage. This allows for new derived types to be introduced with no change to the code that uses the base class. Use of this pattern makes it possible to interchange concrete implementations without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code. Used correctly the "extra work" pays off in the second implementation of the factory.
Classic Computer Science Problems
Benefits of the Abstract Factory Pattern:
The following lists the benefits of using the Abstract Factory pattern:
- Isolates concrete classes.
- Makes exchanging product families easy.
- Promotes consistency among products.
When to Use the Abstract Factory Pattern:
You should use the Abstract Factory pattern when:
- The system should be independent of how its prodcuts are created, composed, and represented.
- The system should be configured with one of multiple families of products a) MS Windows or b) Apple Macintosh
- The family of related product objects is designed to be used together, and you must enforce this constraint. This is the key point of the pattern, otherwise you could use a Factory Pattern.
Intent of the Abstract Factory Pattern
- Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
- The Abstract Factory pattern is very similar to the Factory Method pattern. One difference between the two is that ith the Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition whereas the Factory Method pattern uses inheritance and relies on a subclass to handle the desired object instantiation.
- Actually, the delegated object frequently uses factory methods to perform the instantiation.
Gang of Four Patterns
Definitions
- A realization is a semantic relationship between classifiers, where one classifier specifies a contract that another classifier guarantees to carry out.
- Generalization relationship is an association with a small triangle next to the class being inherited from whereas an aggregation relationship is an association with a diamond next to the class representing the aggregate.
Abstract Factory Pattern Code