Discussion of creating patterns

discussion of creating patterns

There are two common ways to parameterize a system with classes of objects created by a system. One is the subclass of the class that generated the object, which corresponds to using the FactoryMethod (3.3) pattern. The main disadvantage of this approach is that you may need to create a new subclass just to change the product class. Such changes may be cascaded (cascade). For example, if the creator of the product itself is created by a factory method, you must also redefine the creator of it.

Another way to parameterize a system is to rely more on object compositing: Defining an object that is responsible for defining the Product object class and taking it as a parameter to the system. This is a key feature of the Abstractfactory (3.1), Builder (3.2), and prototype (3.4) modes. All of these three patterns involve creating a new "factory object" that is responsible for creating product objects. Abstractfactory objects that produce multiple classes from this factory object. Builder uses a relatively complex protocol from this factory object to step through the creation of a complex product. Prototype creates product objects by copying prototype objects by the factory object. In this case, the factory object and the prototype are the same object because the prototype is responsible for returning the Product object.

Consider the drawing editor framework that is described in prototype mode. There are a number of ways to parameterize Graphictool by product classes:

With FactoryMethod mode, a subclass of Graphictool is created for each graphic subclass in the selection board. Graphictool will have a newgraphic operation, and each graphictool subclass would redefine it. With the abstractfactory pattern, there will be a graphicsfactory class hierarchy corresponding to each graphic subclass. In this case, only one product is created per factory: Circlefactory will create circle,linefactory will create line, and so on. Graphictool will be used as a parameter to create a factory of the right kind graphic. With the prototype pattern, each graphic subclass will implement the clone operation, and Graphictool will take the prototype of the graphic it creates as a parameter.

Exactly which model is best depends on many factors. In our drawing editor frame, at first glance, the FactoryMethod mode is the simplest to use. It is easy to define a new subclass of Graphictool, and the Graphictool instance is created only when the selection plate is defined. Its main disadvantage is the proliferation of Graphictool subclasses, and none of them do much.

Abstractfactory has not been greatly improved, as it requires an equally large graphicsfactory class hierarchy. Abstractfactory is a little better than factorymethod only if there is already a Graphicsfactory class level- Either because the compiler provides it automatically (like in Smalltalk or Objectivec) or because the other parts of the system require this graphicsfactory class hierarchy.

In general, the prototype pattern may be best for the drawing editor framework because it requires only one clone operation for each graphics class. This reduces the number of classes, and clone can be used for other purposes rather than purely instantiation (for example, a duplicate menu operation).

FactoryMethod enables a design to be customized and slightly complex. Other design patterns require new classes, and FactoryMethod only requires a new operation. People usually use FactoryMethod as a standard way to create objects. However, this is not necessary when the instantiated class does not change at all or when the instantiation appears in an operation that the subclass can easily redefine, such as in an initialization operation.

Designs that use Abstractfactory, prototype, or builder are even more flexible than those designed to use FactoryMethod, but they are also more complex. Typically, the design begins with FactoryMethod, and when the designer discovers that more flexibility is needed, the design evolves to other creation patterns. When you weigh the design criteria, understanding multiple patterns can give you more leeway to choose.