The Strategy Design Pattern is a behavioral design pattern that enables selecting an algorithm's implementation at runtime. Instead of implementing a single algorithm directly, a class can be designed to use multiple algorithms interchangeably. The Strategy pattern encapsulates each algorithm inside a separate class, known as a strategy class, allowing them to be switched in and out as required. This design aids in decoupling the algorithm's definition from its usage.
Why C++ Programmers Should Study It
Flexibility Allows dynamic swapping of algorithms based on runtime conditions.
Encapsulation Encapsulates algorithm variations, making them interchangeable.
Maintainability Simplifies maintenance by decoupling algorithm implementation from its context.
Scalability Eases addition of new strategies without altering the context.
Reusability Facilitates algorithm reuse across different contexts or applications.
Testability Enhances testability by isolating the context from the strategy.
Design Cleanliness Promotes cleaner design by separating concerns and reducing conditional statements.
The Strategy design pattern implemented in C++. We'll create three classes: Strategy, ConcreteStrategyA, and ConcreteStrategyB. The Strategy class is an interface defining a family of algorithms, while `ConcreteStrategyA` and `ConcreteStrategyB` are concrete implementations of these algorithms.
We'll also create a Context class which maintains a reference to a `Strategy` object and allows the client to switch between different strategies dynamically.
Let's start with the header files:
Strategy.h
// Abstract Strategy class
class Strategy {
public:
virtual ~Strategy() {}
virtual void execute() = 0;
};
ConcreteStrategyA.h
#include "Strategy.h"
// Concrete Strategy A class
class ConcreteStrategyA : public Strategy {
public:
void execute() override;
};
ConcreteStrategyB.h
#include "Strategy.h"
// Concrete Strategy B class
class ConcreteStrategyB : public Strategy {
public:
void execute() override;
};
Context.h
#include "Strategy.h"
// Context class
class Context {
public:
Context(Strategy* strategy);
void setStrategy(Strategy* strategy);
void executeStrategy();
private:
Strategy* strategy_;
};
Now let's implement these classes:
ConcreteStrategyA.cpp
#include <iostream>
#include "ConcreteStrategyA.h"
void ConcreteStrategyA::execute() {
std::cout << "Executing Concrete Strategy A\n";
// Implementation of strategy A
}
ConcreteStrategyB.cpp</b>
#include <iostream>
#include "ConcreteStrategyB.h"
void ConcreteStrategyB::execute() {
std::cout << "Executing Concrete Strategy B\n";
// Implementation of strategy B
}
Executing Concrete Strategy A
Executing Concrete Strategy B>
This demonstrates the Strategy design pattern, where the behavior of the `Context` object can be changed dynamically by switching between different `Strategy` objects.
Why PHP Programmers Should Study the State Design Pattern:
Simplified MaintenanceEnables easier updates and bug fixes by localizing state behavior.
Enhanced Scalability Facilitates adding new states and behaviors without modifying existing code.
Improved Readability Makes complex state logic more understandable and organized.
Flexibility in Development Offers a flexible foundation for evolving application requirements and features.
Reusability Across Projects Promotes reusing state-specific logic in different parts of the application or in future projects.
Efficient State Management Streamlines handling of state transitions and associated actions, improving performance.
Encourages Good Practices Fosters use of design principles and patterns, improving overall code quality and architectur
1. State.php (The Abstract State) Stateis an abstract class that serves as a blueprint for all possible states the context could be in.
Attributes: $context: This attribute holds a reference to the Context class. This allows each concrete state to interact and potentially change the current state of the context.
Methods:
- setContext(Context $context): Allows setting a reference to the Context object for a state. This is essential for any concrete state that wishes to transition the context to another state.
- handle1(): An abstract method which defines how this state responds to the request1 method call on the context. Concrete states will provide their own implementation.
- handle2(): Similarly, an abstract method defining the behavior for the request2 method call on the context. Again, the concrete states will provide specific implementations.
abstract class State
{
/**
* @var Context
*/
protected $context;
public function setContext(Context $context)
{
$this->context = $context;
}
abstract public function handle1(): void;
abstract public function handle2(): void;
}
2. Context.php (The Context) Context is the main class in the State pattern. It holds a reference to the current state and allows clients to trigger state transitions and behaviors.
Attributes:
- $state: This holds the current state of the context. It's of type State, so it could be an instance of any of the concrete state classes.
Methods
- __construct(State $state): The constructor initializes the context with a given state and sets it using the transitionTo method.
- transitionTo(State $state): This method allows the context to change its current state. It sets the new state, updates the state's context reference, and then logs the transition.
- request1() and request2(): These methods delegate calls to the current state's respective handle1 and handle2 methods. This is where the actual state-based behavior takes place.
class Context
{
/**
* @var State A reference to the current state of the Context.
*/
private $state;
public function __construct(State $state)
{
$this->transitionTo($state);
}
/**
* The Context allows changing the State object at runtime.
*/
public function transitionTo(State $state): void
{
echo "Context: Transition to " . get_class($state) . ".<br/>";
$this->state = $state;
$this->state->setContext($this);
}
/**
* The Context delegates part of its behavior to the current State object.
*/
public function request1(): void
{
$this->state->handle1();
}
public function request2(): void
{
$this->state->handle2();
}
}
ConcreteStateA.php & ConcreteStateB.php (The Concrete States)
These classes represent specific states the context can be in. They extend the abstract State class and provide concrete implementations for its abstract methods.
ConcreteStateA:
Methods:
- handle1(): Outputs that it's handling request1 and then changes the state of the context to ConcreteStateB.
- handle2(): Outputs that it's handling request2 but doesn't change the state.
ConcreteStateB:
Methods:
- handle1(): Outputs that it's handling request1 but doesn't change the state.
- handle2(): Outputs that it's handling request2 and then changes the state of the context back to ConcreteStateA.
ConcreteStateA.php
class ConcreteStateA extends State
{
public function handle1(): void
{
echo "ConcreteStateA handles request1.<br/>";
echo "ConcreteStateA wants to change the state of the context.<br/>";
$this->context->transitionTo(new ConcreteStateB);
}
public function handle2(): void
{
echo "ConcreteStateA handles request2.<br/>";
}
}
ConcreteStateB.php
class ConcreteStateB extends State
{
public function handle1(): void
{
echo "ConcreteStateB handles request1.<br/>";
}
public function handle2(): void
{
echo "ConcreteStateB handles request2.<br/>";
echo "ConcreteStateB wants to change the state of the context.<br/>";
$this->context->transitionTo(new ConcreteStateA);
}
}
4. index.php (Client Code)
This script sets everything in motion. It includes all necessary files and then:
- Creates a new Context object with an initial state of ConcreteStateA .
- Calls request1() on the context, triggering ConcreteStateA's handle1() method.
- Calls request2() on the context, which at this point triggers ConcreteStateB's handle2() method due to the state transition in the previous step.
In essence, the design pattern shown here allows the `Context` class to change its behavior when its internal state changes, without modifying the class itself. The behavior for each state is encapsulated in the concrete state classes. The context simply delegates the requests to these state objects.
index.php
Context: Transition to ConcreteStateA.
ConcreteStateA handles request1.
ConcreteStateA wants to change the state of the context.
Context: Transition to ConcreteStateB.
ConcreteStateB handles request2.
ConcreteStateB wants to change the state of the context.
Context: Transition to ConcreteStateA.
The Observer Design Pattern is a behavioral pattern that sets up a one-to-many dependency between objects. When the state of one object (known as the "Subject") changes, all of its dependents ("Observers") are notified and updated automatically. The Subject maintains a list of its Observers and offers mechanisms to add, remove, or notify them.
In this pattern, there are mainly four classes: Subject, ConcreteSubject, Observer, and ConcreteObserver. Each class serves a specific role in implementing the pattern.
Here's an example of how you can structure and implement the Observer design pattern in Java:
The `Subject` interface defines methods that allow objects to register as observers, remove themselves as observers, and notify all observers when a change occurs.
2. ConcreteSubject.java
import java.util.ArrayList;
import java.util.List;
public class ConcreteSubject implements Subject {
private List<Observer> observers = new ArrayList<>();
private int state;
public int getState() {
return state;
}
public void setState(int state) {
this.state = state;
notifyObservers();
}
@Override
public void addObserver(Observer observer) {
observers.add(observer);
}
@Override
public void removeObserver(Observer observer) {
observers.remove(observer);
}
@Override
public void notifyObservers() {
for (Observer observer : observers) {
observer.update();
}
}
}
`ConcreteSubject` is a class that implements the `Subject` interface. It maintains a list of observers and notifies them when its state changes.
3. Observer.java
public interface Observer {
void update();
}
The `Observer` interface declares an `update` method that concrete observers will implement to respond to changes in the subject's state.
4. ConcreteObserver.java
public class ConcreteObserver implements Observer {
private String name;
private ConcreteSubject subject;
public ConcreteObserver(String name, ConcreteSubject subject) {
this.name = name;
this.subject = subject;
subject.addObserver(this);
}
@Override
public void update() {
int newState = subject.getState();
System.out.println(name + " received an update: State is now " + newState);
}
}
`ConcreteObserver` is a class that implements the `Observer` interface. It registers itself with a `ConcreteSubject` during construction and responds to updates by printing a message.
5. Main.java
public class Main {
public static void main(String[] args) {
ConcreteSubject subject = new ConcreteSubject();
ConcreteObserver observer1 = new ConcreteObserver("Observer 1", subject);
ConcreteObserver observer2 = new ConcreteObserver("Observer 2", subject);
subject.setState(10);
subject.setState(20);
}
}
In the `Main` class, we create a `ConcreteSubject` and two `ConcreteObserver` instances. We then change the subject's state twice, which triggers notifications to the observers.
Order to create classes:
1. `Subject` interface
2. `ConcreteSubject` class
3. `Observer` interface
4. `ConcreteObserver` class
5. `Main` class
When you run the code, you should see the following output:
Observer 1 received an update: State is now 10
Observer 2 received an update: State is now 10
Observer 1 received an update: State is now 20
Observer 2 received an update: State is now 20
This output demonstrates that both observers are notified and updated when the subject's state change
