This document discusses the prototype design pattern, which specifies the kind of objects to create using a prototypical instance and creates new objects by copying its prototype. It allows specifying new objects at runtime without creating many classes or inheritance structures. The prototype pattern is useful when object initialization is expensive and there will be few variations, as it avoids expensive creation from scratch by cloning pre-initialized prototypes instead. Some consequences are that object classes can be added or removed dynamically by cloning prototypes as needed.

1. Prototype Design
Pattern

2. Overview
1. Brief Last Week
2. Intent
3. Implement in JavaScript
4. Problem & Solve
5. Benefits
6. Consequences
7. When
8. Rule of Thumb

3. Brief Last Week
1. Builder Pattern
2. Finalise what is presentations

4. Intent
1. Specifying the kind of objects to create using a
prototypical instance
2. Creating new objects by copying its prototype

5. Implement in JavaScript
Diagram

6. 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
6

8. Problem & Solve
1. Avoid subclasses of an object creator
2. Avoid in the inherent cost of creating a new
object in the standard way

9. Benefits
1. 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

10. 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.

11. 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.

12. 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.

13. Rule of Thumbs
• Abstract Factory classes are often implemented
with Factory Methods, but they can be
implemented using Prototype.

14. Rule of Thumbs
• Factory Method: creation through inheritance.
Protoype: creation through delegation.

15. 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.

16. Rule of Thumbs
• Prototype doesn't require subclassing, but it does
require an "initialize" operation. Factory Method
requires subclassing, but doesn't require Initialize.

17. Rule of Thumbs
• Designs that make heavy use of the Composite
and Decorator patterns often can benefit from
Prototype as well.

18. Rule of Thumbs
• Prototype co-opts one instance of a class for use
as a breeder of all future instances.

19. 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.

20. 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.