Discussing Design Patterns -- Strategy Pattern

[Julia Reynolds]

This is the next pattern on our list.
Intent (from http://www.evl.uic.edu/benjamin/StrategyPattern/strategyTut1.htm)
Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithm vary independently from clients that use it.
Also Known as
Policy
Motivation
You have a situation whereby you manipulate a set of objects in different ways
depending on the algorithm.
For instance, a word processor may have several line breaking strategies.
It manipulates lines, paragraphs and characters.
You don't want a case statement in the client that explicity specifies each strategy.
This makes it difficult to vary existing algorithms and add new ones.
http://www.tml.hut.fi/~pnr/Tik-76.278/gof/html/Strategy.html

[This message has been edited by Julia Reynolds (edited June 19, 2001).]

[Desai Sandeep]

Hi,
This looks to be a derivation of the Polymorphism GRASP Pattern.
The other Patterns which comes to my mind which addresses similar issues are State Pattern and Role Pattern.
The specific behavior of the class is taken care by the Class(subtype) itself since it is an Expert to handle that behavior.The case statements in the client would be reduced since the behavior is encapsulated in the object.
Hope this helps,
Sandeep
PS : Let us come out with some code based on this pattern.
-- Sandeep
[This message has been edited by Desai Sandeep (edited June 20, 2001).]

[Junilu Lacar]

Here are a couple of scenarios that I thought might be candidates for application of the Strategy pattern:
1. In an accounting application, one might have many different types of transactions. Each transaction had different types of processing. So each transaction could be a different strategy.
2. In an application that can have users using different UIs, e.g. web browser, swing application, cell phone, it is desirable to separate the logic that handles presentation from the logic that handles business rules. Each way of presenting the "model" in a UI would be a different strategy.
Comments on suitability of the Strategy pattern?

[Desai Sandeep]

Hi,
These are some of my views on Strategy Pattern.
When do you use it?

1. Many related classes differ only in their behaviour.
   
2. Strategies provide a way to configure a class with one of many behaviors.
   
3. You need different variants of an algorithm.
   
4. An algorithm uses data that client shouldn't know about.
   
5. Avoid exposing complex, algorithm-specific data structure.
   
6. A class defines many behaviors, and these appear as multiple condition statements in its operations.
   

Sample code implementing Strategy pattern


<pre><font size=+0>
import java.io.*; 
public interface InterfaceAlgorithm { 
    public void executeAlgorithm(); 
}//End of Interface
public class Algorithm1 implements InterfaceAlgorithm { 
    public void executeAlgorithm() { 
        prt();
    } 
    public void prt() {
        System.out.println(" Class is Algorithm1.");
    } 
}//End of Class 

public class Algorithm2 implements InterfaceAlgorithm { 
    public void executeAlgorithm() { 
        prt();
    } 
    public void prt() { 
        System.out.println(" Class is Algorithm2.");
    } 
}//End of Class 

public class Context  { 
    public Context(InterfaceAlgorithm algo){
        _algo = algo; 
    } 
    public void contextInterface() { 
         _algo.executeAlgorithm(); 
    } 
    private InterfaceAlgorithm _algo; 
} //End of Class 
</font></pre>


In the above code InterfaceAlgorithm interface common to all supported algorithm classes Algorithm1 and Algorithm2. Class Context is configured with different algorithm object either object of Algorithm1 class or Algorithm2 class and maintains a reference to InterfaceAlgorithm type class.
Advantage
Scalability of J2EE components which uses this pattern.Developing application as J2EE component makes it pluggable and portable. With regards to the type of bean to be used used in J2EE component, it is going to depend upon the situation.
We need to come up with some code on this!

Drawbacks



1. Adds communication overhead between objects.
   
2. Increased number of objects.
   

Hope this helps,
Sandeep
PS : I am working on some J2EE code based on Strategy Pattern.Will post it as soon as I am done with it.
- Sandeep
[This message has been edited by Desai Sandeep (edited June 22, 2001).]

[Jaydeep Rege]

I see Strategy pattern as a right candidate only when there are many variations of a complex algorithm which can't be put inside a Switch block.
I can still achieve transparency to Client without going for Strategy pattern. That can be done by adding one more abstraction layer.

[Jacky Chow]

hi all, I have a question about the use of Context in Strategy Pattern, could anyone tell me what's the benefits of using the Context other than use a concrete strategy directly?

<pre><font size=+0>
 
import java.io.*; 
 
public interface InterfaceAlgorithm { 
 
    public void executeAlgorithm(); 
 
}//End of Interface
 
public class Algorithm1 implements InterfaceAlgorithm { 
 
    public void executeAlgorithm() { 
        prt();
    } 
 
    public void prt() {
        System.out.println(" Class is Algorithm1.");
    } 
 
}//End of Class 
 
 
public class Algorithm2 implements InterfaceAlgorithm { 
 
    public void executeAlgorithm() { 
        prt();
    } 
 
    public void prt() { 
        System.out.println(" Class is Algorithm2.");
    } 
 
}//End of Class 
 
 
public class Context  { 
 
    public Context(InterfaceAlgorithm algo){
        _algo = algo; 
    } 
 
    public void contextInterface() { 
         _algo.executeAlgorithm(); 
    } 
 
    private InterfaceAlgorithm _algo; 
 
} //End of Class 
</font></pre>

In the above code InterfaceAlgorithm interface common to all supported algorithm classes Algorithm1 and Algorithm2. Class Context is configured with different algorithm object either object of Algorithm1 class or Algorithm2 class and maintains a reference to InterfaceAlgorithm type class.

Advantage
Scalability of J2EE components which uses this pattern.Developing application as J2EE component makes it pluggable and portable. With regards to the type of bean to be used used in J2EE component, it is going to depend upon the situation.

We need to come up with some code on this!


Drawbacks

1. Adds communication overhead between objects.
2. Increased number of objects.



Hope this helps,
Sandeep

PS : I am working on some J2EE code based on Strategy Pattern.Will post it as soon as I am done with it.

- Sandeep

[This message has been edited by Desai Sandeep (edited June 22, 2001).][/qb]

---

</blockquote>
[ August 11, 2004: Message edited by: Jacky Chow ]

[Ilja Preuss]

Originally posted by Jaydeep Rege:
I see Strategy pattern as a right candidate only when there are many variations of a complex algorithm which can't be put inside a Switch block.

A strongly disagree. The problem with a switch block is that it most likely violates the Open Closed Principle - if you want to modify the behaviour (e.g. add another variant), you need to modify the switch statement instead of just implementing another strategy object. This adds significantly to maintenance burden in my experience.

I can still achieve transparency to Client without going for Strategy pattern. That can be done by adding one more abstraction layer.

I'm not sure I understand you. Could you please elaborate?

[Stan James]

I'm with Ilja (as usual) on open-closed. We are using strategies in a core component that must handle new product types without modification. We built a strategy factory that obtains the strategy for each product type based on configuration files. The core looks like:

public Object handle( AbstractProduct product )
{
   function = "search";
   StragetyInterface strategy = factory.getStrategyFor( product.type + function );
   strategy.execute( product );
}

"product" in this case is a data only object generated from a Rose model. We cannot add behavior to it, so we put the behavior in strategies. Each product has a family of strategies for search, retrieve, update, etc. The goal was (and my bonus depends on) being able to add products without redeploying the core.

Now that I said "family" maybe it should have been:

factory = factoryFactory.getFactoryFor(product);
strategy = factory.getSearchStrategy();
strategy.execute(product);