Creator (GRASP)

GRASP Pattern: Creator

 * Name | **Creator** |
 * Problem | Who should be responsible for creating a new instance of some class? |
 * Solution | Make B responsible for creating A if... |
 * | - B contains or is a composition of A |
 * | - B records A |
 * | - B closely uses A |
 * | - B has the data to initialize A |

Problem
One of the first problems to consider in OO design is "Who creates object X?" (doing responsibility). The decision has to support //low representational gap// (LRG) between how we think of the domain and a straightforward correspondence with software objects. This connects the UP Domain Model to the UP Design Model, and our mental model of the domain to its realization in the domain layer of the software architecture.

The creation of objects is one of the most common activities in an object-oriented system. Consequently, it is useful to have a general principle for the assignment of creation responsibilities. Assigned well, the design can support low coupling, increased clarity, encapsulation, and reusability.

Solution
B is a //creator// of A objects. The more matches the better.

If more than one option applies, usually prefer a class B which //agregates// or //contains// class A.

\\

Example
In the example of a Square, consistent with LRG and the Creator advice, a Board manages the creation of Squares. Also, several Square objects will always be a part of one Board, and Board manages their creation and destruction. Therefore, they are in a //composite aggregation// association with the Board.

\\

Discussion
Creator guides the assigning of responsibilities related to the creation of objects, a very common task. The basic intent of the Creator pattern is to find a creator that needs to be connected to the created object in any event. Choosing it as the creator supports low coupling.

Composite //aggregates// Part, Container //contains// Content, and Recorder //records// Recorded. These are all very common relationships between classes in a class diagram. Creator suggests that the enclosing container or recorder class is a good candidate for the responsibility of creating the thing contained or recorded. Of course, this is only a guideline.

Note that we turned to the concept of //composition// in considering the Creator pattern. A composite object is an excellent candidate to make its part.

Sometimes you identify a creator by looking for the class that has the initializing data that will be passed in during creation. This is actually an example of the Expert pattern. Initializing data is passed in during creation via some kind of initialization method. For exmaple, assume that a Payment instance, when created needs to be initialized with the Sale total. Since Sale knows the total, Sale is a candidate creator of the Payment.

\\

Contradictions
Often, creation requires significant complexity, such as using recycled instances for performance, conditionally creating an instance from one of a family of similar classes based upon some external property value, asn so forth. In these cases, it is advisable to delegate creation to a helper class called a Concrete Factory or an Abstract Factory rather than use the class suggested by Creator.

\\

Benefits
Low coupling is supported, which implies lower maintenance dependencies and higher opportunities for reuse. Coupling is probably not increased because the created class is likely already visible to the creator class, due to the existing associations that motivated its choice as creator.

\\

Related Patterns or Principles

 * Low Coupling
 * Concrete Factory and Abstract Factory
 * Whole-Part desribes a pattern to define aggregate objects that support encapsulation of components.