Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Discussing Design Patterns -- Strategy Pattern

 
Ranch Hand
Posts: 123
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Sheriff
Posts: 16767
281
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

  7. Sample code implementing Strategy pattern

    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.

    3. 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).]
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?




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.



  3. 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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:

"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:

reply
    Bookmark Topic Watch Topic
  • New Topic