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
The Memento design pattern is all about capturing and storing the current state of an object in a manner that allows it to be restored later on, without breaking the principles of encapsulation.
The Order of Creating Classes:
1. Memento: This stores the internal state of the `Originator` object.
2. Originator: This is the object whose state we want to save and restore. It creates a memento and restores its state from it.
3. Caretaker: It keeps track of multiple mementos. It helps maintain the history of states.
Explanation and Code:
Memento.cs
using System;
public class Memento
{
private string _state;
public Memento(string state)
{
_state = state;
}
public string GetState()
{
return _state;
}
}
This class is responsible for storing the state of the `Originator`. It has a method to retrieve the state.
Originator.cs
public class Originator
{
private string _state;
// Set a new state
public void SetState(string state)
{
_state = state;
}
// Get current state
public string GetState()
{
return _state;
}
// Save state to memento
public Memento SaveStateToMemento()
{
return new Memento(_state);
}
// Restore state from memento
public void GetStateFromMemento(Memento memento)
{
_state = memento.GetState();
}
}
The Originator class can create a snapshot of its current state by using the SaveStateToMemento method. It can also restore its state using a given Memento object.
Caretaker.cs
using System.Collections.Generic;
public class Caretaker
{
private List<Memento> _mementoList = new List<Memento>();
public void Add(Memento state)
{
_mementoList.Add(state);
}
public Memento Get(int index)
{
return _mementoList[index];
}
}
The `Caretaker` maintains a list of memento objects and can add new mementos or retrieve existing ones.
Program.cs
using System;
class Program
{
static void Main(string[] args)
{
Originator originator = new Originator();
Caretaker caretaker = new Caretaker();
// Changing and saving states
originator.SetState("State #1");
caretaker.Add(originator.SaveStateToMemento());
originator.SetState("State #2");
caretaker.Add(originator.SaveStateToMemento());
originator.SetState("State #3");
caretaker.Add(originator.SaveStateToMemento());
originator.SetState("State #4");
Console.WriteLine("Current State: " + originator.GetState());
// Restoring previous states
originator.GetStateFromMemento(caretaker.Get(0));
Console.WriteLine("First saved State: " + originator.GetState());
originator.GetStateFromMemento(caretaker.Get(1));
Console.WriteLine("Second saved State: " + originator.GetState());
}
}
In Program.cs, we create instances of the Originator and Caretaker classes. We then change the state of the Originator multiple times and save these states using the Caretaker. Finally, we demonstrate restoring the Originator to its previous states.
This is a basic implementation of the Memento pattern in C#. The real power comes in when you have complex objects with multiple fields and need to maintain versions of those objects over time.
The Mediator design pattern is used to centralize complex communications and control between related objects, making it easier to decouple them. Here's a simple example using a chat room (Mediator) where users (Colleagues) can send messages to each other:
1. 'Mediator.h`
This is an abstract class that declares the `sendMessage` method.
#include <string>
class User;
class Mediator {
public:
virtual void sendMessage(const std::string& message, User* user) = 0;
};
2. `User.h`
This represents a colleague class. Each user knows about the mediator and can send messages.
3. `ChatRoom.h`
This concrete mediator allows users to send messages to each other.
#include "Mediator.h"
#include "User.h"
#include <vector>
class ChatRoom : public Mediator {
private:
std::vector<User*> _users;
public:
void addUser(User* user) {
_users.push_back(user);
}
void sendMessage(const std::string& message, User* user) override {
for (User* u : _users) {
// Don't send the message back to the sender
if (u != user) {
u->receiveMessage(user->getName() + ": " + message);
}
}
}
};
4. `main.cpp`
This is a simple demo using the classes.
cpp
#include "ChatRoom.h"
int main() {
ChatRoom chatRoom;
User* alice = new User(&chatRoom, "Alice");
User* bob = new User(&chatRoom, "Bob");
chatRoom.addUser(alice);
chatRoom.addUser(bob);
alice->sendMessage("Hi Bob!");
bob->sendMessage("Hello Alice!");
delete alice;
delete bob;
return 0;
}
When you run this, you will get:
Bob received: Alice: Hi Bob!
Alice received: Bob: Hello Alice!
Explanation:
1. Mediator: Abstract class to define the contract for concrete mediators.
2. User: Represents the colleagues that will communicate using the Mediator.
3. ChatRoom: Concrete mediator that allows `User` instances to communicate with each other.
4. main.cpp: Demonstrates the usage of the pattern.
The idea is that a `User` doesn't communicate with other users directly. Instead, they use the `ChatRoom` (mediator) to pass messages. The mediator then decides how to propagate that message, allowing for easy modification of behavior without changing the `User` classes.
To demonstrate the Iterator design pattern in PHP, we'll create a simple example that iterates over a collection of books. The Iterator pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Project Structure Book.php - Represents a single book. BookList.php - Represents a collection of books. BookListIterator.php - An iterator for the BookList. index.php - Demonstrates the usage of the iterator.
Step-by-Step Creation and Explanation
1. Book.php
This class represents a single book. It's a simple class with a constructor and a getter method for the book's title.
title = $title;
}
public function getTitle() {
return $this->title;
}
}
2. BookList.php
This class represents a collection of Book objects. It stores books and provides methods to add or remove a book from the list.
books[] = $book;
}
public function removeBook(Book $book) {
foreach ($this->books as $key => $b) {
if ($b->getTitle() === $book->getTitle()) {
unset($this->books[$key]);
}
}
$this->books = array_values($this->books);
}
public function count() {
return count($this->books);
}
public function getBook($index) {
if (isset($this->books[$index])) {
return $this->books[$index];
}
return null;
}
}
3. BookListIterator.php
This class implements the iterator for BookList. It allows traversing over the BookList collection.
bookList = $bookList;
}
public function hasNext() {
return $this->currentBook < $this->bookList->count();
}
public function next() {
return $this->bookList->getBook($this->currentBook++);
}
}
4. index.php
This file demonstrates the usage of the above classes. It creates a list of books, adds them to the BookList, and then iterates over them using BookListIterator.
addBook(new Book("1984"));
$bookList->addBook(new Book("To Kill a Mockingbird"));
$bookList->addBook(new Book("The Great Gatsby"));
// Iterate over book list
$iterator = new BookListIterator($bookList);
while ($iterator->hasNext()) {
$book = $iterator->next();
echo $book->getTitle() . "\n";
}
Running the Code
When you run index.php, you should see the titles of the books printed one after the other:
1984
To Kill a Mockingbird
The Great Gatsby
This output demonstrates the Iterator pattern in action, allowing you to sequentially access elements of the BookList without exposing its internal structure.
The Interpreter design pattern is used to provide a way to evaluate language grammar for particular languages. Here's a simple example using the pattern to interpret basic arithmetic expressions:
code
Expression.java - This is the abstract expression class that declares an interpret method.
public interface Expression {
int interpret();
}
NumberExpression.java - This is a terminal expression that implements the Expression interface for numbers.
public class NumberExpression implements Expression {
private int number;
public NumberExpression(int number) {
this.number = number;
}
@Override
public int interpret() {
return this.number;
}
}
AddExpression.java - This is a non-terminal expression that implements the Expression interface for the addition operation.
public class AddExpression implements Expression {
private Expression firstExpression;
private Expression secondExpression;
public AddExpression(Expression firstExpression, Expression secondExpression) {
this.firstExpression = firstExpression;
this.secondExpression = secondExpression;
}
@Override
public int interpret() {
return this.firstExpression.interpret() + this.secondExpression.interpret();
}
}
SubtractExpression.java - This is a non-terminal expression for the subtraction operation.
public class SubtractExpression implements Expression {
private Expression firstExpression;
private Expression secondExpression;
public SubtractExpression(Expression firstExpression, Expression secondExpression) {
this.firstExpression = firstExpression;
this.secondExpression = secondExpression;
}
@Override
public int interpret() {
return this.firstExpression.interpret() - this.secondExpression.interpret();
}
}
Demo.java - This is the client class to demonstrate the Interpreter pattern.
public class Demo {
// Typically, there would be a parser here to convert a string expression into the
// Expression tree. For simplicity, we'll hand-code the tree.
public static void main(String[] args) {
Expression addExpression = new AddExpression(new NumberExpression(5), new NumberExpression(3));
System.out.println("Result of 5 + 3: " + addExpression.interpret());
Expression subtractExpression = new SubtractExpression(new NumberExpression(5), new NumberExpression(3));
System.out.println("Result of 5 - 3: " + subtractExpression.interpret());
}
}
Order of creating classes:
Expression.java - Define the interface for our expression tree. NumberExpression.java - Define how numbers will be interpreted. AddExpression.java and SubtractExpression.java - Define non-terminal expressions for addition and subtraction. Demo.java - Use the above expressions to demonstrate the pattern.
Explanation:
Expression is an interface with the interpret method that all terminal and non-terminal expressions will implement.
NumberExpression is a terminal expression. It simply returns its number value when interpret is called.
AddExpression and SubtractExpression are non-terminal expressions. They contain two expressions and when interpret is called, they perform their respective operations on the results of the interpret calls of their contained expressions.
Demo constructs an expression tree and then evaluates it using the interpret method. In a real-world scenario, you'd probably have a parser that converts a string representation of an expression into this tree.
