The abstract factory pattern is a software creational design pattern that provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. 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 and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
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 and to create families of related objects without having to depend on their concrete classes. 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. Additionally, higher levels of separation and abstraction can result in systems which are more difficult to debug and maintain. Therefore, as in all software designs, the trade-offs must be carefully evaluated.
Read more about Abstract Factory Pattern: Definition, Usage, Example
Famous quotes containing the words abstract, factory and/or pattern:
“What persuades men and women to mistake each other from time to time for gods or vermin is ideology. One can understand well enough how human beings may struggle and murder for good material reasons—reasons connected, for instance, with their physical survival. It is much harder to grasp how they may come to do so in the name of something as apparently abstract as ideas. Yet ideas are what men and women live by, and will occasionally die for.”
—Terry Eagleton (b. 1943)
“The man who builds a factory builds a temple, that the man who works there worships there, and to each is due, not scorn and blame, but reverence and praise.”
—Calvin Coolidge (1872–1933)
“The worthiest man to be known, and for a pattern to be presented to the world, he is the man of whom we have most certain knowledge. He hath been declared and enlightened by the most clear-seeing men that ever were; the testimonies we have of him are in faithfulness and sufficiency most admirable.”
—Michel de Montaigne (1533–1592)