Creates Relationship

• Abstract Factory
• Builder
• Factory Method
• Command
• Memento

This post examines how design patterns incorporating a creates relationship uses that relationship to make a loosely structured design to complete one or more kinds of tasks.

Uses of Creates

In virtually any OOP programming, some sort of creates relationship exists; sometimes no more than a Client instantiating an instance of a class. However, when dealing with design patterns, we are looking for a specific purpose in terms of the overall design for the use of a creates relationship. For example, in the Memento pattern, the Originator instantiates a Memento object with the following code:

1
2
3
4
5

public function createMemento ():Memento
{
       trace ("Creating memento with current state");
       return new Memento(mstate);
}

In the Memento pattern, the Memento class has an aggregate relationship with the Caretaker participant which stores the current state in an array (in our example.) In looking closely at the relationship between the Originator and the Memento, when the Originator instantiates an instance of the Memento, it is really acting as a setter—it sets a specified state as the memento, which in turn is stored by the Caretaker when called upon. Effectively, the process decouples the Originator from the Caretaker.

Factory Work

In thinking of the create relationship, one of the Factory designs most likely comes to mind. Not surprisingly, both the Abstract Factory and Factory Method include a create relationship. The Concrete Creator class has a create relationship with the Product class. The whole concept of a factory is one where something is created, and that’s exactly where we’d expect to find a create relationship.

One apparent exception is the Flyweight Design Pattern. No create relationship is seen in the Class Diagram, but in looking at the Factory participant in the design, you will find that elements in an associative array are made up of instantiated ConcreteFlyweight instances. (Associative arrays in ActionScript 3.0 are created as Objects and the elements are the Object properties.) The more complex multiple aggregation masks the create relationship.

The Uses-A Relationship

Of all of the ways to describe what happens with the dashed line and arrow, I prefer the uses-a description. This is consistent with has-a (composition) and is-a (inheritance) relationships. It’s easy to say that Participant A uses a Participant B object through instantiation. GoF simply call it the creates relationship (p. 364), and let it go at that. Scott Myers in his book Effective C++ uses the term is-implemented-in-terms-of to reference such a relationship. Myers points out, IS-IMPLEMENTED-IN-TERMS-OF is a relationship between classes that exists in the implementation domain. The implementation domain is contrasted with the application domain where you have has-a relationships (composition.)

In any event, this concludes our series on relationships between design pattern participants. We hope it helps you better understand what all of the symbols mean, and while the lines of demarcation between types of relationships may become blurred, at least you have the basics so that you can better understand a design pattern’s class diagram and what’s going on in a pattern. Start looking at your own code in terms of these relationships, and Who knows?, maybe you’ll discover you’ve been using one that you didn’t realize before.

Your valuable comments are welcomed as always, along with questions, insights and examples.