Prototype
JaninaVoigt (Talk | contribs) |
JaninaVoigt (Talk | contribs) (→Consequences) |
||
Line 33: | Line 33: | ||
==Consequences== | ==Consequences== | ||
+ | * Hides the concrete product classes from the client, reducing the number of classes that clients need to know about. This adds flexibility and means that new products can be added without affecting clients. | ||
+ | * New products can be added and removed at runtime by simply creating a new prototype for clients to copy. | ||
+ | * There is no need for the Creator class hierarchy as there is with other patterns like [[Factory Method]]. | ||
+ | |||
+ | |||
+ | ==Liabilities== | ||
+ | * Implementing the Clone() method can be difficult, especially when the internal objects of the products don't support copying or there are circular references that complicate copying. | ||
==Related Patterns== | ==Related Patterns== |
Revision as of 05:28, 24 July 2009
Contents |
Intent
The Prototype pattern allows you to specify what objects you want to create once, and then create new ones by copying a prototype object.
Structure
The Prototype class declares the clone() method, which is implemented by all subclasses as a way to return a copy of itself. Each Client is instantiated with an equivalent Prototype class, it creates a new Prototype object by telling it's Prototype to clone itself.
Usage
The Prototype pattern should be used when a system needs to be independent of how it's products are created, composed and represented. AND:
- When the classes to instantiate are specified at run time, OR
- To avoid building parallel hierarchies of factories and products, OR
- When an instance of a class can be only one of a few different states. The Prototype pattern may be more convenient than instantiating the class manually each time with the appropriate state.
Example
A good example for this pattern is given in the Gang of Four Design Patterns book. They describe a music score editor, which is built by adding music objects such as Notes and Staves to a graphical editor framework. The graphical editor also has Tools for manipulating Graphic objects, such as selecting, moving etc. There must also be a way to create Graphic objects and add them to the editor, which they call GraphicTool which is a subclass of Tool. The example diagram from the book is below:
The GraphicTool class creates a problem. It is part of the graphical editor framework, and doesn't know how to create music objects such as Notes and Staves etc. One solution would be to create sublcasses of GraphicTool for each music object that we need to create, however these subclasses would only differ in the type of music object that they create. This would also create the Parallel hierarchies problem.
The solution is to make the GraphicTool create a new Graphic by "cloning" an instance of a subclass of Graphic. This cloned instance is called a prototype. Each GraphicTool object is initialized with the prototype that it is designated to create. Each GraphicTool instance will add it's music object to the score by cloning it's prototype and adding the clone to the score. The GraphicTool class can clone any type of Graphic as long as all Graphic subclasses support the clone() method.
Consequences
- Hides the concrete product classes from the client, reducing the number of classes that clients need to know about. This adds flexibility and means that new products can be added without affecting clients.
- New products can be added and removed at runtime by simply creating a new prototype for clients to copy.
- There is no need for the Creator class hierarchy as there is with other patterns like Factory Method.
Liabilities
- Implementing the Clone() method can be difficult, especially when the internal objects of the products don't support copying or there are circular references that complicate copying.
Related Patterns
See also
Design patterns | |
---|---|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton |