Strategy pattern

In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm's behavior to be selected at runtime. The strategy pattern

defines a family of algorithms,
encapsulates each algorithm, and
makes the algorithms interchangeable within that family.

Strategy lets the algorithm vary independently from clients that use it.^[1] Strategy is one of the patterns included in the influential book Design Patterns by Gamma et al. that popularized the concept of using patterns to describe software design.

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication.

The essential requirement in the programming language is the ability to store a reference to some code in a data structure and retrieve it. This can be achieved by mechanisms such as the native function pointer, the first-class function, classes or class instances in object-oriented programming languages, or accessing the language implementation's internal storage of code via reflection.

Structure

Strategy Pattern in UML

Strategy pattern in LePUS3 (legend)

Example

C#

//The interface for the strategies
public interface ICalculate 
{  
   int Calculate(int value1, int value2);
}

//strategies
//Strategy 1: Minus
class Minus : ICalculate 
{
    public int Calculate(int value1, int value2) 
    {
        return value1 - value2;
    }
}

//Strategy 2: Plus
class Plus : ICalculate 
{
    public int Calculate(int value1, int value2) 
    {
        return value1 + value2;
    }
}

//The client
class CalculateClient 
{
    private ICalculate calculateStrategy;

    //Constructor: assigns strategy to interface
    public CalculateClient(ICalculate strategy) 
    {
        this.calculateStrategy = strategy;
    }

    //Executes the strategy
    public int Calculate(int value1, int value2) 
    {
        return calculateStrategy.Calculate(value1, value2);
    }
}

//Initialize
protected void Page_Load(object sender, EventArgs e) 
{
    CalculateClient minusClient = new CalculateClient(new Minus());
    Response.Write("<br />Minus: " + minusClient.Calculate(7, 1).ToString());

    CalculateClient plusClient = new CalculateClient(new Plus());
    Response.Write("<br />Plus: " + plusClient.Calculate(7, 1).ToString());
}

Java

The following example is in Java.

import java.util.ArrayList;
import java.util.List;

public class StrategyPatternWiki {

	public static void main(String[] args) {
		Customer a = new Customer(new NormalStrategy());

		// Normal billing
		a.add(1.0, 1);

		// Start Happy Hour
		a.setStrategy(new HappyHourStrategy());
		a.add(1.0, 2);

		// New Customer
		Customer b = new Customer(new HappyHourStrategy());
		b.add(0.8, 1);
		// The Customer pays
		a.printBill();

		// End Happy Hour
		b.setStrategy(new NormalStrategy());
		b.add(1.3, 2);
		b.add(2.5, 1);
		b.printBill();

	}
}

class Customer {

	private List<Double> drinks;
	private BillingStrategy strategy;

	public Customer(BillingStrategy strategy) {
		this.drinks = new ArrayList<Double>();
		this.strategy = strategy;
	}

	public void add(double price, int quantity) {
		drinks.add(strategy.getActPrice(price * quantity));
	}

	// Payment of bill
	public void printBill() {
		double sum = 0;
		for (Double i : drinks) {
			sum += i;
		}
		System.out.println("Total due: " + sum);
		drinks.clear();
	}

	// Set Strategy
	public void setStrategy(BillingStrategy strategy) {
		this.strategy = strategy;
	}

}

interface BillingStrategy {
	public double getActPrice(double rawPrice);
}

// Normal billing strategy (unchanged price)
class NormalStrategy implements BillingStrategy {

	@Override
	public double getActPrice(double rawPrice) {
		return rawPrice;
	}

}

// Strategy for Happy hour (50% discount)
class HappyHourStrategy implements BillingStrategy {

	@Override
	public double getActPrice(double rawPrice) {
		return rawPrice*0.5;
	}

}

A much simpler example in "modern Java" (Java 8 and later), using lambdas, may be found here.

Strategy and open/closed principle

Accelerate and brake behaviors must be declared in each new car model.

According to the 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 functionalities for 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. 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 specific classes that implement 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();

/* Encapsulated family of Algorithms 
 * Interface and its implementations
 */
public interface IBrakeBehavior {
    public void brake(); 
}

public class BrakeWithABS implements IBrakeBehavior {
    public void brake() {
        System.out.println("Brake with ABS applied");
    }
}

public class Brake implements IBrakeBehavior {
    public void brake() {
        System.out.println("Simple Brake applied");
    }
}


/* Client which can use the algorithms above interchangeably */
public abstract class Car {
    protected IBrakeBehavior brakeBehavior;
    
    public void applyBrake() {
        brakeBehavior.brake();
    }

    public void setBrakeBehavior(IBrakeBehavior brakeType) {
        this.brakeBehavior = brakeType;
    }
}

/* Client 1 uses one algorithm (Brake) in the constructor */
public class Sedan extends Car {
    public Sedan() {
        this.brakeBehavior = new Brake();
    }
}

/* Client 2 uses another algorithm (BrakeWithABS) in the constructor */
public class SUV extends Car {
    public SUV() {
        this.brakeBehavior = new BrakeWithABS();
    }
}


/* Using the Car Example */
public class CarExample {
    public static void main(String[] args) {
        Car sedanCar = new Sedan();
        sedanCar.applyBrake();  // This will invoke class "Brake"

        Car suvCar = new SUV(); 
        suvCar.applyBrake();    // This will invoke class "BrakeWithABS"

        // set brake behavior dynamically
        suvCar.setBrakeBehavior( new Brake() ); 
        suvCar.applyBrake();    // This will invoke class "Brake" 
    }
}

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

References

Wikimedia Commons has media related to Strategy (design pattern).

↑ Eric Freeman, Elisabeth Freeman, Kathy Sierra and Bert Bates, Head First Design Patterns, First Edition, Chapter 1, Page 24, O'Reilly Media, Inc, 2004. ISBN 978-0-596-00712-6

External links

Strategy Pattern in UML (Spanish, but english model)

The Wikibook Computer Science Design Patterns has a page on the topic of: Strategy implementations in various languages

Software design patterns

Gang of Four
patterns

Creational	Abstract factory Builder Factory method Prototype Singleton

Structural	Adapter Bridge Composite Decorator Facade Flyweight Proxy

Behavioral	Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor

Concurrency
patterns

Architectural
patterns

Other
patterns

Books

People

Communities

This article is issued from Wikipedia - version of the Saturday, April 16, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.