Strategy pattern

UML class and sequence diagram In the above UML class diagram, the Context class does not implement an algorithm directly. Instead, Context refers to the Strategy interface for performing an algorithm (strategy.algorithm()), which makes Context independent of how an algorithm is implemented. The Strategy1 and Strategy2 classes implement the Strategy interface, that is, implement (encapsulate) an algorithm. The UML sequence diagram shows the runtime interactions: The Context object delegates an algorithm to different Strategy objects. First, Context calls algorithm() on a Strategy1 object, which performs the algorithm and returns the result to Context. Thereafter, Context changes its strategy and calls algorithm() on a Strategy2 object, which performs the algorithm and returns the result to Context. Class diagram Image:Strategy pattern in LePUS3.gif|thumb|none|400px|Strategy pattern in LePUS3 (legend) == Strategy and open–closed principle ==

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. This is compatible with the open–closed principle (OCP), which proposes that classes should be open for extension but closed for modification. 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 runtime 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: Brake* brakeBehavior = new Brake(); package org.wikipedia.examples; /* Encapsulated family of Algorithms * Interface and its implementations */ interface IBrakeBehavior { public void brake(); } class BrakeWithABS implements IBrakeBehavior { public void brake() { System.out.println("Brake with ABS applied"); } } class Brake implements IBrakeBehavior { public void brake() { System.out.println("Simple Brake applied"); } } // Client that can use the algorithms above interchangeably abstract class Car { private IBrakeBehavior brakeBehavior; public Car(IBrakeBehavior brakeBehavior) { this.brakeBehavior = brakeBehavior; } public void applyBrake() { brakeBehavior.brake(); } public void setBrakeBehavior(IBrakeBehavior brakeType) { this.brakeBehavior = brakeType; } } // Client 1 uses one algorithm (Brake) in the constructor class Sedan extends Car { public Sedan() { super(new Brake()); } } // Client 2 uses another algorithm (BrakeWithABS) in the constructor class SUV extends Car { public SUV() { super(new BrakeWithABS()); } } // Using the Car example public class CarExample { public static void main(String[] arguments) { 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" } } ==See also==