Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
You could build an editor for music scores by customizing a general framework for graphical editors and adding new objects that represent notes, rests, and staves. The editor framework may have a palette of tools for adding these music objects to the score. The palette would also include tools for selecting, moving, and otherwise manipulating music objects. Users will click on the quarter-note tool and use it to add quarter notes to the score. Or they can use the move tool to move a note up or down on the staff, thereby changing its pitch. Lets assume the framework provides an abstract Graphic class for graphical components, like notes and staves. Moreover, itll provide an abstract Tool class for defining tools like those in the palette. The framework also predefines a GraphicTool subclass (Client in the thumbnail) for tools that create instances of graphical objects and add them to the document. But GraphicTool presents a problem to the framework designer. The classes for notes and staves are specific to our application, but the GraphicTool class belongs to the framework. GraphicTool doesnt know how to create instances of our music classes to add to the score. We could subclass GraphicTool for each kind of music object, but that would produce lots of subclasses that differ only in the kind of music object they instantiate. We know object composition is a flexible alternative to subclassing. The question is, how can the framework use it to parameterize instances of GraphicTool by the class of Graphic theyre supposed to create? The solution lies in making GraphicTool create a new Graphic by copying or "cloning" an instance of a Graphic subclass. We call this instance a prototype. GraphicTool is parameterized by the prototype it should clone and add to the document. If all Graphic subclasses support a Clone operation, then the GraphicTool can clone any kind of Graphic. So in our music editor, each tool for creating a music object is an instance of GraphicTool thats initialized with a different prototype. Each GraphicTool instance will produce a music object by cloning its prototype and adding the clone to the score.
This pattern has been used on the following systems: Etgdb, an ET++-based debugger front end, provides a point-and-click interface to different line-oriented debuggers. A corresponding DebuggerAdaptor subclass is in each debugger. ModeComposers "interaction technique library" stores prototypes of objects that support various interaction techniques. (Shan, Y-P., MoDE: A UIMS for Smalltalk. In ACM OOPSLA/ECOOP 90 Conference Proceedings, pp. 258-268, Ottawa, Ontario, Canada, October 1990. ACM Press.)
Abstract Factory, Composite, and Decorator patterns
Abstract Factory pattern, Prototype pattern, Composite pattern, Decorator pattern, creational patterns, Gamma patterns, object creation, system parameterization, cloning, object (copy)
any system requiring abstraction for object creation
need a family of related product objects to be used together and you need enforcement of this constraintneed a system to support multiple families of classesneed interface to create objects without knowing their types
isolates concrete classesmakes exchanging product families easypermits adding and removing products at runtimepermits specifying new objects by altering structurepermits specifying new objects by altering valuespromotes consistency among productsreduces subclassing
each subclass of Prototype must implement the Clone operation
Test driver Test.javaSimple implementation of the pattern - Prototype class. Prototype.javaSimple implementation of the pattern - ConcretePrototype2 class. ConcretePrototype2.javaSimple implementation of the pattern - ConcretePrototype1 class. ConcretePrototype1.javaSimple implementation of the pattern - Client class. Client.javaTest driver testprototype.cppSimple implementation of the pattern. prototype.h