16.7. Creator

Assign class B the responsibility to create an instance of class A if one or more of the following is true:

• B aggregates A objects.

• B contains A objects.

• B records instances of A objects.

• B closely uses A objects.

• B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).

B is a creator of A objects.

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

Who should be responsible for creating a new instance of some class?

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.

In the POS application, who should be responsible for creating a SalesLineItem instance? By Creator, we should look for a class that aggregates, contains, and so on, SalesLineItem instances. Consider the partial domain model in Figure 16.7.

Since a Sale contains (in fact, aggregates) many SalesLineItem objects, the Creator pattern suggests that Sale is a good candidate to have the responsibility of creating SalesLineItem instances.

This leads to a design of object interactions as shown in Figure 16.8.

This assignment of responsibilities requires that a makeLineItem method be defined in Sale.

Once again, the context in which these responsibilities were considered and decided upon was while drawing an interaction diagram. The method section of a class diagram can then summarize the responsibility assignment results, concretely realized as methods.

Creator guides assigning 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.

Aggregate aggregates Part, Container contains Content, and Recorder records Recorded 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 the concept of aggregation has been used in considering the Creator pattern. Aggregation is discussed in Chapter 27; a brief definition is that aggregation involves things that are in a strong Whole-Part or Assembly-Part relationship, such as Body aggregates Leg or Paragraph aggregates Sentence.

Sometimes a creator is found 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, such as a Java constructor that has parameters. For example, assume that a Payment instance needs to be initialized, when created, with the Sale total. Since Sale knows the total, Sale is a candidate creator of the Payment.

Often, creation requires significant complexity, such as using recycled instances for performance reasons, conditionally creating an instance from one of a family of similar classes based upon some external property value, and so forth. In these cases, it is advisable to delegate creation to a helper class called a Factory [GHJV95] rather than use the class suggested by Creator. Factories are discussed in Chapter 23.

• Low coupling (described next) 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.

  Benefits

  
  

• Low Coupling

  Related Patterns or Principles

  
  

• Factory

• Whole-Part [BMRSS96] describes a pattern to define aggregate objects that support encapsulation of components.