Date post: | 19-Aug-2014 |
Category: |
Education |
Upload: | thaichor-seng |
View: | 159 times |
Download: | 1 times |
Prototype Design Pattern
Overview1. Brief Last Week
2. Intent
3. Implement in JavaScript
4. Problem & Solve
5. Benefits
6. Consequences
7. When
8. Rule of Thumb
Brief Last Week1. Builder Pattern
2. Finalise what is presentations
Intent1. Specifying the kind of objects to create
using a prototypical instance
2. Creating new objects by copying its prototype
Implement in JavaScript
Diagram
Implement in JavaScript
Participants
The objects participating in this pattern are:• Client -- In sample code: the run() function.
creates a new object by asking a prototype to clone itself• Prototype -- In sample code: CustomerPrototype
creates an interfaces to clone itself• Clones -- In sample code: Customer
the cloned objects that are being created
Problem & Solve1. Avoid subclasses of an object creator
2. Avoid in the inherent cost of creating a new object in the standard way
Benefits1. It eliminates the (potentially expensive)
overhead of initialising an object
2. It simplifies and can optimise the use case where multiple objects of the same type will have mostly the same data
Consequences• You can add and remove classes at runtime
by cloning them as needed.• You can revise the internal data
representation of a class at runtime based on program conditions.
• You can also specify new objects at runtime without creating a proliferation of classes and inheritance structures.
When• Use the Prototype pattern when a system should be
independent of how its products are created, composed, and represented.
• When the classes to instantiate are specified at run-time, for example, by dynamic loading
• To avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
• When instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.
Rule of Thumbs• Sometimes creational patterns are
competitors: there are cases when either Prototype or Abstract Factory could be used properly. At other times they are complementory: Abstract Factory might store a set of Prototypes from which to clone and return product objects. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
Rule of Thumbs• Abstract Factory classes are often
implemented with Factory Methods, but they can be implemented using Prototype.
Rule of Thumbs• Factory Method: creation through
inheritance. Protoype: creation through delegation.
Rule of Thumbs• Often, designs start out using Factory
Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Protoype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
Rule of Thumbs• Prototype doesn't require subclassing, but
it does require an "initialize" operation. Factory Method requires subclassing, but doesn't require Initialize.
Rule of Thumbs• Designs that make heavy use of the
Composite and Decorator patterns often can benefit from Prototype as well.
Rule of Thumbs• Prototype co-opts one instance of a class
for use as a breeder of all future instances.
Rule of Thumbs• Prototypes are useful when object
initialization is expensive, and you anticipate few variations on the initialization parameters. In this context, Prototype can avoid expensive "creation from scratch", and support cheap cloning of a pre-initialized prototype.
Rule of Thumbs• Prototype is unique among the other
creational patterns in that it doesn't require a class – only an object. Object-oriented languages like Self and Omega that do away with classes completely rely on prototypes for creating new objects.