Strategy Pattern Article Index for
Strategy 		Website Links For
Strategy 		 

Information About

Strategy Pattern
  CATEGORIES ABOUT STRATEGY PATTERN
   
software design patterns
   
articles with example c sharp code
   
articles with example java code
   
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...



In some programming languages, such as those without Polymorphism , the issues addressed by this pattern are handled through forms of Reflection , such as the native function Pointer or function Delegate syntax.

The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.


DIAGRAM



CODE EXAMPLES


C#



using System;

namespace Wikipedia.Patterns.Strategy
{
// MainApp test application
class MainApp
{
static void Main()
{
Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyA());
context.Execute();

context = new Context(new ConcreteStrategyB());
context.Execute();

context = new Context(new ConcreteStrategyC());
context.Execute();

}
}

// The classes that implement a concrete strategy should implement this
// The context class uses this to call the concrete strategy
interface IStrategy
{
void Execute();
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyA : IStrategy
{
public void Execute()
{
Console.WriteLine( "Called ConcreteStrategyA.Execute()" );
}
}

class ConcreteStrategyB : IStrategy
{
public void Execute()
{
Console.WriteLine( "Called ConcreteStrategyB.Execute()" );
}
}

class ConcreteStrategyC : IStrategy
{
public void Execute()
{
Console.WriteLine( "Called ConcreteStrategyC.Execute()" );
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context
{
IStrategy strategy;

// Constructor
public Context(IStrategy strategy)
{
this.strategy = strategy;
}

public void Execute()
{
strategy.Execute();
}
}
}



Java



package wikipedia.patterns.strategy;

// MainApp test application
class MainApp {

public static void main(String {Link without Title} args) {
Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyA());
context.execute();

context = new Context(new ConcreteStrategyB());
context.execute();

context = new Context(new ConcreteStrategyC());
context.execute();
}
}

// The classes that implement a concrete strategy should implement this
// The context class uses this to call the concrete strategy
interface IStrategy {
void execute();
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyA implements IStrategy {
public void execute() {
System.out.println( "Called ConcreteStrategyA.execute()" );
}
}

class ConcreteStrategyB implements IStrategy {
public void execute() {
System.out.println( "Called ConcreteStrategyB.execute()" );
}
}

class ConcreteStrategyC implements IStrategy {
public void execute() {
System.out.println( "Called ConcreteStrategyC.execute()" );
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {
IStrategy strategy;

// Constructor
public Context(IStrategy strategy) {
this.strategy = strategy;
}

public void execute() {
strategy.execute();
}
}



STRATEGY VERSUS BRIDGE


The UML class diagram for the Strategy pattern is the same as the diagram for the Bridge Pattern . However, these two design patterns aren't the same in their ''intent''. While the Strategy pattern is meant for ''behavior'', the Bridge Pattern is meant for ''structure''.

The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.


STRATEGY PATTERN AND OCP


According to Strategy pattern, the behaviors of a class should not be inherited, instead they should be encapsulated using interfaces. As an example, consider a car class. Two possible behaviors of car are brake and accelerate.

Since accelerate and brake behaviors change frequently between models, a common approach is to implement these behaviors in subclasses. This approach has significant drawbacks: accelerate and brake behaviors must be declared in each new Car model. This may not be a concern when there are only a small number of models, but the work of managing these behaviors increases greatly as the number of models increases, and requires code to be duplicated across models. Additionally, it is not easy to determine the exact nature of the behavior for each model without investigating the code in each.

The strategy pattern uses composition instead of inheritance. In the strategy pattern behaviors are defined as separate interfaces and abstract 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. For instance, a car object’s brake behavior can be changed from BrakeWithABS() to Brake() by changing the brakeBehavior member to:

brakeBehavior = new Brake();

This gives greater flexibility in design and is in harmony with OCP (Open Closed Principle) that states classes should be open for extension but closed for modification.


SEE ALSO



EXTERNAL LINKS