1.Topics‎ > ‎Architecture‎ > ‎Patterns‎ > ‎a.Design Patterns‎ > ‎D.Behavioral Patterns‎ > ‎

Strategy Pattern

  1. Strategy Pattern 
    1. Define a family of algorithms, encapsulate each one, and make them interchangeable.
    2. Strategy lets the algorithm vary independently from clients that use it.
    3. Fundamentally is implements SRP by obeying the SRP guideline " Encapsulate what varies" and "Program to Interface"
  2. When to Use
    1. When classes differs only in behavioral aspect
  3. Example 
    1. Dogs (Class) and their barking styles (strategy)
  4. Overview Tutorials 
    1. http://www.oodesign.com/strategy-pattern.html
  5. Implementation 
    1. The context object receives requests from the client and delegates them to the strategy object.
    2. Usually the ConcreteStartegy is created by the client and passed to the context. From this point the clients interacts only with the context.
  6. Class Diagram

  7. Specific Considerations
    1. Passing data to/from Strategy object
      1. Usually each strategy need data from the context have to return some processed data to the context. This can be achieved in 2 ways.
        1. Creating some additional classes to encapsulate the specific data. 
        2. Passing the context object itself to the strategy objects so that strategy object can set returning data directly in the context. 
      2. When data should be passed the drawbacks of each method should be analyzed. For example, if some classes are created to encapsulate additional data, a special care should be paid to what fields are included in the classes. Maybe in the current implementation all required fields are added, but maybe in the future some new strategy concrete classes require data from context which are not include in additional classes. Another fact should be specified at this point: it's very likely that some of the strategy concrete classes will not use field passed to the in the additional classes.
      3. On the other side, if the context object is passed to the strategy then we have a tighter coupling between strategy and context.
    2. Families of related algorithms 
      1. The strategies can be defined as a hierarchy of classes offering the ability to extend and customize the existing algorithms from an application. At this point the composite design pattern can be used with a special care.
    3. Optionally Concrete (Default) Strategy Objects
      1. It's possible to implement a context object that carries an implementation for default or a basic algorithm. While running it, it checks if it contains a strategy object. If not it will run the default code and that's it. If a strategy object is found, it is called instead (or in addition) of the default code. 
      2. This is an elegant solution to exposing some customization points to be used only when they are required. Otherwise the clients don't have to deal with Strategy objects.
    4. Strategy and Factory Patterns
      1. In the classic implementation of the pattern the client should be aware of the strategy concrete classes. 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. 
      2. 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.
    5. Strategy and Bridge
      1. Both of the patterns have the same UML diagram. But they differ in their intent since the strategy is related with the behavior and bridge is for structure. 
      2. Furthermore, the coupling between the context and strategies is tighter that the coupling between the abstraction and implementation in the bring pattern.