Editing Abstract factory pattern (section)

==Usage==
The factory determines the concrete type of object to be created, and it is here that the object is actually created. However, the factory only returns a reference (in Java, for instance, by the '''new''' [[operator (programming)|operator]]) or a [[pointer (computer programming)|pointer]] of an abstract type to the created concrete object.

This insulates client code from [[object creation]] by having clients request that a [[factory object]] create an object of the desired [[abstract type]] and return an abstract pointer to the object.<ref>{{cite web | url = http://www.codeproject.com/ | title = Object Design for the Perplexed | first = David | last = Veeneman | date = 2009-10-23 | publisher = The Code Project | archive-url = https://web.archive.org/web/20110221224616/http://www.codeproject.com/ | archive-date = 2011-02-21 | access-date = 2012-05-16 | quote = The factory insulates the client from changes to the product or how it is created, and it can provide this insulation across objects derived from very different abstract interfaces. | url-status = bot: unknown }}</ref>

An example is an abstract factory class <code>DocumentCreator</code> that provides interfaces to create a number of products (e.g., <code>createLetter()</code> and <code>createResume()</code>). The system would have any number of derived concrete versions of the <code>DocumentCreator</code> class such as<code>FancyDocumentCreator</code> or <code>ModernDocumentCreator</code>, each with a different implementation of <code>createLetter()</code> and <code>createResume()</code> that would create corresponding objects such as<code>FancyLetter</code> or <code>ModernResume</code>. Each of these products is derived from a simple [[abstract class]] such as<code>Letter</code> or <code>Resume</code> of which the client is aware. The client code would acquire an appropriate [[Instance (computer science)|instance]] of the <code>DocumentCreator</code> and call its [[factory method]]s. Each of the resulting objects would be created from the same <code>DocumentCreator</code> implementation and would share a common theme. The client would only need to know how to handle the abstract <code>Letter</code> or <code>Resume</code> class, not the specific version that was created by the concrete factory.

As the factory only returns a reference or a pointer to an abstract type, the client code that requested the object from the factory is not aware of&mdash;and is not burdened by&mdash;the actual concrete type of the object that was created. However, the abstract factory knows the type of a concrete object (and hence a concrete factory). For instance, the factory may read the object's type from a configuration file. The client has no need to specify the type, as the type has already been specified in the configuration file. In particular, this means:

* The client code has no knowledge of the concrete [[Data type|type]], not needing to include any [[header file]]s or [[Class (computer science)|class]] [[Declaration (computer science)|declaration]]s related to it. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their [[abstract interface|abstract interfaces]].<ref name="implementation">{{cite web | url = http://www.oodesign.com/abstract-factory-pattern.html | title = Abstract Factory: Implementation | publisher = OODesign.com | access-date = 2012-05-16
}}</ref>
* Adding new concrete types is performed by modifying the client code to use a different factory, a modification that is typically one line in one file. The different factory then creates objects of a different concrete type but still returns a pointer of the ''same'' abstract type as before, thus insulating the client code from change. This is significantly easier than modifying the client code to instantiate a new type. Doing so would require changing every location in the code where a new object is created as well as ensuring that all such code locations have knowledge of the new concrete type, for example, by including a concrete class header file. If all factory objects are stored globally in a [[singleton pattern|singleton]] object, and all client code passes through the singleton to access the proper factory for object creation, then changing factories is as easy as changing the singleton object.<ref name="implementation" />