Tuesday, October 23, 2012

Strategy Design Pattern

Although they are lots of books and articles about Design Patterns, yet I would like to share my point of view about common design patterns and would be happy to have your thoughts on comments. This post introduces GoF Strategy design pattern.

Definition
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. (DoFactory)


  • Context is configured with a ConcreteStrategy object and maintains a reference to a Strategy object. Context may define an interface that lets Strategy access its data.
  • Strategy and Context interact to implement the chosen algorithm. A context may pass all data required by the algorithm to the strategy when the algorithm is called. Alternatively, the context can pass itself as an argument to Strategy operations. That lets the strategy call back on the context as required.
  • A context forwards requests from its clients to its strategy. Clients usually create and pass a ConcreteStrategy object to the context; thereafter, clients interact with the context exclusively. There is often a family of ConcreteStrategy classes for a client to choose from.
  • Usually each strategy need data from the context have to return some processed data to the context. This can be achieved in two ways:
    • Creating some additional classes to encapsulate the specific data.
    • Passing the context object itself to the strategy objects. The strategy object can set returning data directly in the context. 


Applicability

  • Many related classes differ only in their behavior 
  • You need different variant of an Algorithm
  • An algorithm uses data that clients should not know about
  • A class defines many behaviors, and these appear as multiple conditional statement in its operations.

Consequences
  • The strategy pattern uses aggregation instead of inheritance. In the strategy pattern, behaviors are defined as separate interfaces and specific classes that implement these interfaces. Specific classes encapsulate these interfaces. This allows better decoupling between the behavior and the class that uses the behavior. The behavior can be changed without breaking the classes that use it, and the classes can switch between behaviors by changing the specific implementation used without requiring any significant code changes. Behaviors can also be changed at run-time as well as at design-time.
  • Eliminates conditional statements
  •  The strategy design pattern splits the behavior (there are many behaviors) of a class from the class itself and defines families of related algorithms or behaviors for contexts to reuse and select.

Downsides
  • The main draw back of Strategy Pattern is that a client must understand how the Strategies differ. Since clients get exposed to implementation issues the strategy design pattern should be used only when the variation in behavior is relevant to them. In order to decouple the client class from strategy classes is possible to use a factory class inside the context object to create the strategy object to be used. By doing so the client has only to send a parameter (like a string) to the context asking to use a specific algorithm, being totally decoupled of strategy classes.
  • Communication overhead between strategy and context.
  • All algorithms should use the same Strategy interface.

Sample Code



Related Patterns

State: State is like Strategy except in its intent.Strategy is a bind-once pattern, whereas State is more dynamic

Template MethodStrategy is like Template Method except in its granularity. Strategy pattern is an alternative to sub-classing by encapsulating the algorithm in separate strategy classes lets you vary the algorithm independently of its context, making it easier to switch, understand and extend.

Decorator: Strategy lets you change the guts of an object. Decorator lets you change the skin.
Flyweight: Strategy objects often make good flyweights.

No comments :

Post a Comment