Command pattern

• Command pattern

command pattern is a behavioural design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

Three terms always associated with the command pattern are client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

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

• Rules of thumb

    Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Command normally specifies a sender-receiver connection with a subclass.
    Chain of Responsibility can use Command to represent requests as objects.
    Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
    Command can use Memento to maintain the state required for an undo operation.
    MacroCommands can be implemented with Composite.
    A Command that must be copied before being placed on a history list acts as a Prototype.
    Two important aspects of the Command pattern: interface separation (the invoker is isolated from the receiver), time separation (stores a ready-to-go processing request that’s to be stated later)
http://sourcemaking.com/design_patterns/command

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

Object Pool Pattern

• Object Pool Design Pattern

Intent

Object pooling can offer a significant performance boost; it is most effective in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instantiations in use at any one time is low.

Problem

Object pools (otherwise known as resource pools) are used to manage the object caching. A client with access to a Object pool can avoid creating a new Objects by simply asking the pool for one that has already been instantiated instead. Generally the pool will be a growing pool, i.e. the pool itself will create new objects if the pool is empty, or we can have a pool, which restricts the number of objects created.


Example

Do you like bowling? If you do, you probably know that you should change your shoes when you getting the bowling club. Shoe shelf is wonderful example of Object Pool. Once you want to play, you’ll get your pair (aquireReusable) from it. After the game, you’ll return shoes back to the shelf (releaseReusable).

Rules of thumb

    The Factory Method pattern can be used to encapsulate the creation logic for objects. However, it does not manage them after their creation, the object pool pattern keeps track of the objects it creates.
    Object Pools are usually implemented as Singletons.

http://sourcemaking.com/design_patterns/object_pool

• Object pool pattern

The object pool pattern is a software creational design pattern that uses a set of initialised objects kept ready to use, rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object, which is a specific type of factory object, to the pool rather than destroying it

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

• Object Pool Pattern

The Object Pool lets others "check out" objects from its pool, when those objects are no longer needed by their processes, they are returned to the pool in order to be reused.
http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/objectpool.html

Builder Pattern

• Builder  Pattern

Intent

    Separate the construction of a complex object from its representation so that the same construction process can create different representations.
    Parse a complex representation, create one of several targets.
http://sourcemaking.com/design_patterns/builder

• Builder pattern

he intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects. Often, the builder pattern is used to build products in accordance with the composite pattern.
http://en.wikipedia.org/wiki/Builder_pattern

Private class data pattern

• Private class data pattern

Intent

The private class data design pattern seeks to reduce exposure of attributes by limiting their visibility. It reduces the number of class attributes by encapsulating them in single Data object. It allows the class designer to remove write privilege of attributes that are intended to be set only during construction, even from methods of the target class.

Consequences

The consequences of using this design pattern include the following:

    Controlling write access to class attributes;
    Separating of data from methods that use it;
    Encapsulating class attribute (data) initialization; and
    Providing new type of final: final after constructor.

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