Creator pattern

This article publishes a draft of a previously unreleased object-oriented design pattern

Please see also the UML diagrams of the Creator pattern on the next pages

The Creator design pattern provides a way to create objects of any generalized or concrete type, where the concrete type and the initialization of the created object is choosen by any arbitrary dynamic or static context and the client which invokes the creation has no dependency to the creating object (the factory) or its generalizations. The factory implements the instantiation and further initialization of the object to create, but is never called (directly) by the client itself. If the client invokes the creation of an object for a generalized type, then the client will have no knowledge about and no dependency to the concrete type of that object, which the factory uses to create that object.

The Creator pattern introduces creators. A creator is an object which determines and manages the creation of another object on behalf of the client which invoked the creator. A creator is of a concrete type and specialized for the type of the object that is to be created. Moreover, the creator can be specialized for a specific manner of construction for that type. All creators have at least one common generalization with a public "create" operation which implements the management of the object creation and optionally further related features such as an object life cycle management. A creator is typically instantiated by the client which invokes the "create" operation on that creator, but the creator could also be provided to that client (e.g. for a kind of prototyping). Either way, the client has a dependency to the creator, but no dependency to the factory.

Futhermore, whenever the creation of an object requires to pass arguments to that type, then the respective creator must incorporate these arguments by its own attributes and allow the client to set the respective values into the creator before calling the "create" operation. For instance, when the constructor (or initializing operation) of the concrete type that is to be instantiated requires certain arguments, then the creator must offer operations to set the values (setters) for these arguments to the client, and the creator must offer operations to get the values (getters) for these arguments to the factory which will use these arguments for the creation. Thus, the creator serves as well as a data transfer object between the client and the factory and has typically a similar set of attributes as the object that is created.

As stated initially, the creation of an object depends on a provided dynamic or static context, called creation context, not just on the type (actually the creator type) and the passed arguments. And it shall be possible to use any arbitrary object or set of values to represent that creation context. For instance a context may contain typical properties like system environment, subdomain, product category, product type, customer country, customer category etc., but may contain more dynamic properties like current date, current time, total amount, temperature, pressure, velocity, depth, flight level etc. as well. That means the Creator pattern realizes a multiple dispatch, even with dynamic contexts, on the factory methods used to create objects. Consequently, it requires a separate factory implementation for each separate creation algorithm for the same type of object. And each used creation context must be assigned to exactly one factory, while the same factory might be used in more than one context. So that contexts and factories are assigned in a many-to-one relationship from contexts to factories.