Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Prototype design patterns

1,771 views

Published on

Prototype Design Pattern of GoF

Published in: Education
  • Login to see the comments

Prototype design patterns

  1. 1. Prototype Design Pattern
  2. 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. 3. Brief Last Week 1. Builder Pattern 2. Finalise what is presentations
  4. 4. Intent 1. Specifying the kind of objects to create using a prototypical instance 2. Creating new objects by copying its prototype
  5. 5. Implement in JavaScript Diagram
  6. 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
  7. 7. Problem & Solve 1. Avoid subclasses of an object creator 2. Avoid in the inherent cost of creating a new object in the standard way
  8. 8. 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
  9. 9. 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.
  10. 10. 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.
  11. 11. 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.
  12. 12. Rule of Thumbs • Abstract Factory classes are often implemented with Factory Methods, but they can be implemented using Prototype.
  13. 13. Rule of Thumbs • Factory Method: creation through inheritance. Protoype: creation through delegation.
  14. 14. 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.
  15. 15. Rule of Thumbs • Prototype doesn't require subclassing, but it does require an "initialize" operation. Factory Method requires subclassing, but doesn't require Initialize.
  16. 16. Rule of Thumbs • Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.
  17. 17. Rule of Thumbs • Prototype co-opts one instance of a class for use as a breeder of all future instances.
  18. 18. 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.
  19. 19. 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.

×