Monday, November 19, 2012

Prototype Pattern



  • Prototype Pattern


Intent

    Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
    The new operator considered harmful.

Rules of thumb


    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.
    Abstract Factory classes are often implemented with Factory Methods, but they can be implemented using Prototype.
    Factory Method: creation through inheritance. Protoype: creation through delegation.
    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.
    Prototype doesn’t require subclassing, but it does require an “initialize” operation. Factory Method requires subclassing, but doesn’t require Initialize.
    Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.
    Prototype co-opts one instance of a class for use as a breeder of all future instances.
    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.
    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

http://sourcemaking.com/design_patterns/prototype



  • Prototype pattern


The prototype pattern is a creational design pattern used in software development when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used to:

    avoid subclasses of an object creator in the client application, like the abstract factory pattern does.
    avoid the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) when it is prohibitively expensive for a given application.

http://en.wikipedia.org/wiki/Prototype_pattern

No comments:

Post a Comment