Mastering Behavioral Design Patterns in C++ and Python

Mastering Behavioral Design Patterns in C++ and Python

by

Behavioral design patterns serve as the nervous system of modern software architecture, orchestrating the complex flows of communication and responsibility distribution between disparate objects. By decoupling the sender of a request from its receiver and abstracting algorithmic execution, these patterns transform rigid codebases into highly adaptable, maintainable systems capable of evolving alongside business requirements. In high-throughput backend infrastructure, mastering behavioral interactions is critical for preventing spaghetti architecture, mitigating tight coupling, and ensuring thread safety. For software engineers aiming to excel in senior low-level design (LLD) and system design architecture interviews, a deep structural understanding of these eleven Gang of Four (GoF) patterns is non-negotiable.

Table of Contents

Mastering Behavioral Design Patterns in C++ and Python: The Ultimate Low-Level Design Guide

[FEATURED_IMAGE_PLACEHOLDER]

Demystifying Behavioral Patterns in Architecture

At the core of software design, behavioral patterns represent a shift away from structural static composition toward dynamic runtime communication. While creational patterns govern how objects are instantiated and structural patterns manage class composition, behavioral patterns are specifically concerned with the algorithms and assignment of responsibilities between objects. They describe not only the patterns of objects or classes but also the patterns of communication between them. By standardizing these behavioral flows, architects can systematically address runtime decision-making, state propagation, and decoupled event handling.

The architectural value of these patterns lies in their ability to minimize tight coupling between components. In a poorly designed system, changing the behavior of one component often triggers a cascade of breaking changes across the entire codebase. Behavioral design patterns mitigate this fragility by utilizing interfaces, abstract classes, and polymorphism to establish clean, robust contracts. Consequently, objects can interact fluidly without requiring intimate, compile-time knowledge of each other’s internal implementations, making software significantly easier to test, extend, and maintain.

In modern enterprise applications—ranging from reactive microservices to real-time telemetry systems—these patterns are indispensable. They provide the blueprinted solutions for handling asynchronous event processing, parsing complex domain-specific languages, and managing multi-state transactional pipelines. Mastering these patterns allows developers to write self-documenting code that aligns with SOLID principles, ensuring that complex software systems can scale gracefully under heavy operational workloads.

Deep Dive into the Eleven GoF Behavioral Patterns

The Gang of Four (GoF) behavioral patterns are categorized based on whether they operate on classes (using inheritance) or objects (using composition). While they all aim to streamline object interaction, each pattern is designed to solve a highly specific communication bottleneck. Choosing the correct pattern requires analyzing the structural trade-offs, performance overhead, and long-term maintenance costs of the architecture. Implementing these patterns correctly prevents developers from reinventing the wheel when addressing common coordination challenges.

When translating these behavioral patterns into code, developers must navigate the distinct paradigms of statically typed languages like C++ and dynamically typed languages like Python. C++ relies on strict compile-time safety, template metaprogramming, and explicit resource management (RAII), requiring highly structured class hierarchies to ensure memory safety. In contrast, Python leverages its dynamic runtime, first-class functions, and built-in protocols to implement the same architectural patterns with minimal boilerplate and maximum expressive power.

In the following sections, we will dissect each of the eleven GoF behavioral patterns in exhaustive detail. For every pattern, we will explore its historical origin, identify its real-world enterprise use cases, and provide fully functional, production-grade implementations in both C++ and Python. This side-by-side comparison offers an invaluable reference for systems architects who work across diverse, multi-language technology stacks.

1. Chain of Responsibility

History & Origin

The Chain of Responsibility pattern was formulated to decouple the sender of a request from its potential receivers by giving multiple objects a chance to handle the request. This avoided hardcoding a specific handler, which was a major source of coupling in early graphical user interfaces (GUIs) that needed to bubble up click and keyboard events through nested layout structures.

Real-World Industry Use Cases

  • HTTP Middleware Pipelines: Processing requests through authentication, logging, rate-limiting, and caching layers (e.g., Express, Django, or ASP.NET Core middleware).
  • Logging Frameworks: Routing log messages to different destinations (Console, File, Cloud Watch) based on severity levels.
  • Approval Workflows: Processing financial transactions where different management levels must approve purchases based on dollar thresholds.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

enum class SecurityLevel { Low, Medium, High };

struct Request {
    SecurityLevel level;
    std::string description;
};

class Handler {
protected:
    std::shared_ptr nextHandler;
public:
    virtual ~Handler() = default;
    void setNext(std::shared_ptr next) {
        nextHandler = std::move(next);
    }
    virtual void handle(const Request& request) {
        if (nextHandler) {
            nextHandler->handle(request);
        }
    }
};

class LowSecurityHandler : public Handler {
public:
    void handle(const Request& request) override {
        if (request.level == SecurityLevel::Low) {
            std::cout << "[LowSecurityHandler] Handled request: " << request.description << "n";
        } else {
            std::cout << "[LowSecurityHandler] Passing request upstream...n";
            Handler::handle(request);
        }
    }
};

class HighSecurityHandler : public Handler {
public:
    void handle(const Request& request) override {
        if (request.level == SecurityLevel::High) {
            std::cout << "[HighSecurityHandler] Handled critical request: " << request.description << "n";
        } else {
            std::cout << "[HighSecurityHandler] Unhandled security request.n";
            Handler::handle(request);
        }
    }
};

int main() {
    auto low = std::make_shared();
    auto high = std::make_shared();
    low->setNext(high);

    Request r1{SecurityLevel::Low, "Clear browser cache."};
    Request r2{SecurityLevel::High, "Rotate database master keys."};

    low->handle(r1);
    low->handle(r2);
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod
from enum import Enum
from typing import Optional

class SecurityLevel(Enum):
    LOW = 1
    MEDIUM = 2
    HIGH = 3

class Request:
    def __init__(self, level: SecurityLevel, description: str):
        self.level = level
        self.description = description

class Handler(ABC):
    def __init__(self):
        self._next_handler: Optional[Handler] = None

    def set_next(self, handler: "Handler") -> "Handler":
        self._next_handler = handler
        return handler

    @abstractmethod
    def handle(self, request: Request) -> None:
        if self._next_handler:
            self._next_handler.handle(request)

class LowSecurityHandler(Handler):
    def handle(self, request: Request) -> None:
        if request.level == SecurityLevel.LOW:
            print(f"[LowSecurityHandler] Handled request: {request.description}")
        else:
            print("[LowSecurityHandler] Passing request upstream...")
            super().handle(request)

class HighSecurityHandler(Handler):
    def handle(self, request: Request) -> None:
        if request.level == SecurityLevel.HIGH:
            print(f"[HighSecurityHandler] Handled critical request: {request.description}")
        else:
            print("[HighSecurityHandler] Unhandled security request.")
            super().handle(request)

if __name__ == "__main__":
    low_handler = LowSecurityHandler()
    high_handler = HighSecurityHandler()
    low_handler.set_next(high_handler)

    r1 = Request(SecurityLevel.LOW, "Clear browser cache.")
    r2 = Request(SecurityLevel.HIGH, "Rotate database master keys.")

    low_handler.handle(r1)
    low_handler.handle(r2)

2. Command Pattern

History & Origin

The Command pattern was introduced to encapsulate a request as a standalone object containing all information about the request. This allows developers to parameterize clients with different requests, queue or log requests, and support undoable operations. It decoupled the object invoking the operation from the one that knows how to perform it.

Real-World Industry Use Cases

  • GUI Button Actions: Mapping button clicks directly to transactional command objects.
  • Transactional Rollbacks: Storing command execution history to execute reciprocal undo actions.
  • Distributed Job Queues: Serializing command objects to run asynchronously across background worker threads.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

class Light {
public:
    void turnOn() { std::cout << "The light is ON.n"; }
    void turnOff() { std::cout << "The light is OFF.n"; }
};

class Command {
public:
    virtual ~Command() = default;
    virtual void execute() = 0;
    virtual void undo() = 0;
};

class LightOnCommand : public Command {
private:
    std::shared_ptr light;
public:
    explicit LightOnCommand(std::shared_ptr l) : light(std::move(l)) {}
    void execute() override { light->turnOn(); }
    void undo() override { light->turnOff(); }
};

class RemoteControl {
private:
    std::vector<std::shared_ptr> history;
public:
    void submit(const std::shared_ptr& cmd) {
        cmd->execute();
        history.push_back(cmd);
    }
    void undoLast() {
        if (!history.empty()) {
            history.back()->undo();
            history.pop_back();
        } else {
            std::cout << "No commands to undo.n";
        }
    }
};

int main() {
    auto livingRoomLight = std::make_shared();
    auto lightOn = std::make_shared(livingRoomLight);
    RemoteControl remote;

    remote.submit(lightOn);
    remote.undoLast();
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod
from typing import List

class Light:
    def turn_on(self) -> None:
        print("The light is ON.")

    def turn_off(self) -> None:
        print("The light is OFF.")

class Command(ABC):
    @abstractmethod
    def execute(self) -> None:
        pass

    @abstractmethod
    def undo(self) -> None:
        pass

class LightOnCommand(Command):
    def __init__(self, light: Light):
        self._light = light

    def execute(self) -> None:
        self._light.turn_on()

    def undo(self) -> None:
        self._light.turn_off()

class RemoteControl:
    def __init__(self):
        self._history: List[Command] = []

    def submit(self, command: Command) -> None:
        command.execute()
        self._history.append(command)

    def undo_last(self) -> None:
        if self._history:
            cmd = self._history.pop()
            cmd.undo()
        else:
            print("No commands to undo.")

if __name__ == "__main__":
    light = Light()
    light_on_cmd = LightOnCommand(light)
    remote = RemoteControl()

    remote.submit(light_on_cmd)
    remote.undo_last()

3. Interpreter Pattern

History & Origin

The Interpreter pattern defines a representation for a language’s grammar along with an interpreter that uses this representation to evaluate sentences. It was designed to construct simple abstract syntax trees (ASTs) for domain-specific languages (DSLs) without introducing the overhead of complex lexical analyzer generators.

Real-World Industry Use Cases

  • SQL Query Engines: Building internal ASTs to parse and evaluate relational queries.
  • Mathematical Evaluators: Computing arithmetic expressions dynamically in scientific software.
  • Configuration Parsers: Interpreting conditional rules and logic tags in policy engines.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

class Expression {
public:
    virtual ~Expression() = default;
    virtual int interpret(const std::unordered_map& context) = 0;
};

class Number : public Expression {
private:
    int value;
public:
    explicit Number(int val) : value(val) {}
    int interpret(const std::unordered_map&) override { return value; }
};

class Add : public Expression {
private:
    std::shared_ptr left;
    std::shared_ptr right;
public:
    Add(std::shared_ptr l, std::shared_ptr r)
        : left(std::move(l)), right(std::move(r)) {}
    int interpret(const std::unordered_map& context) override {
        return left->interpret(context) + right->interpret(context);
    }
};

int main() {
    std::unordered_map context;
    auto expr = std::make_shared(std::make_shared(10), std::make_shared(5));
    std::cout &lt;&lt; &quot;10 + 5 = &quot; &lt;< expr->interpret(context) &lt;< "n";
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod
from typing import Dict

class Expression(ABC):
    @abstractmethod
    def interpret(self, context: Dict[str, int]) -> int:
        pass

class Number(Expression):
    def __init__(self, value: int):
        self._value = value

    def interpret(self, context: Dict[str, int]) -> int:
        return self._value

class Add(Expression):
    def __init__(self, left: Expression, right: Expression):
        self._left = left
        self._right = right

    def interpret(self, context: Dict[str, int]) -> int:
        return self._left.interpret(context) + self._right.interpret(context)

if __name__ == "__main__":
    context: Dict[str, int] = {}
    expression = Add(Number(10), Number(5))
    print(f"10 + 5 = {expression.interpret(context)}")

4. Iterator Pattern

History & Origin

The Iterator pattern provides a mechanism to access elements of an aggregate collection sequentially without exposing its underlying structural representation (such as trees, lists, or hash tables). This decoupled iterative algorithms from data structures, paving the way for standardized collection libraries.

Real-World Industry Use Cases

  • Database Cursor Iteration: Navigating through records retrieved from relational databases.
  • File Stream Readers: Iterating line-by-line through large binary or text files.
  • Graph Traversals: Sequentially visiting complex structural nodes in social networking graphs.

Production C++ Code Implementation

#include 
#include 
#include 

template 
class Iterator {
public:
    virtual ~Iterator() = default;
    virtual bool hasNext() = 0;
    virtual T next() = 0;
};

template 
class VectorIterator : public Iterator {
private:
    const std::vector& data;
    size_t index = 0;
public:
    explicit VectorIterator(const std::vector& vec) : data(vec) {}
    bool hasNext() override { return index &lt; data.size(); }
    T next() override { return data[index++]; }
};

int main() {
    std::vector numbers = {10, 20, 30};
    VectorIterator it(numbers);
    while (it.hasNext()) {
        std::cout &lt;&lt; it.next() &lt;&lt; &quot; &quot;;
    }
    std::cout &lt;< "n";
    return 0;
}

Production Python Code Implementation

from typing import List, Any

class CustomCollection:
    def __init__(self):
        self._items: List[Any] = []

    def add_item(self, item: Any) -> None:
        self._items.append(item)

    def __iter__(self) -> "CustomIterator":
        return CustomIterator(self._items)

class CustomIterator:
    def __init__(self, items: List[Any]):
        self._items = items
        self._index = 0

    def __next__(self) -> Any:
        try:
            item = self._items[self._index]
            self._index += 1
            return item
        except IndexError:
            raise StopIteration

if __name__ == "__main__":
    collection = CustomCollection()
    collection.add_item("Alpha")
    collection.add_item("Beta")
    collection.add_item("Gamma")

    for item in collection:
        print(item)

5. Mediator Pattern

History & Origin

The Mediator pattern was designed to restrict direct communication between objects, forcing them to collaborate exclusively through a central mediator object. This reduced chaotic, direct N-to-N dependencies in complex systems, turning them into simpler 1-to-N relationships.

Real-World Industry Use Cases

  • Air Traffic Control: Coordinating flights through a central tower rather than having planes communicate directly.
  • UI Form Coordination: Synchronizing multiple interactive components in desktop or web dashboards.
  • Chat Infrastructure: Relaying messages between chat clients via central router hubs.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

class Colleague;

class Mediator {
public:
    virtual ~Mediator() = default;
    virtual void notify(Colleague* sender, const std::string& event) = 0;
};

class Colleague {
protected:
    Mediator* mediator;
public:
    explicit Colleague(Mediator* med) : mediator(med) {}
};

class Component1 : public Colleague {
public:
    using Colleague::Colleague;
    void doA() {
        std::cout &lt;< "Component 1 does A.n";
        mediator->notify(this, "A");
    }
};

class Component2 : public Colleague {
public:
    using Colleague::Colleague;
    void doB() {
        std::cout &lt;&lt; &quot;Component 2 does B.n&quot;;
    }
};

class ConcreteMediator : public Mediator {
private:
    std::unique_ptr c1;
    std::unique_ptr c2;
public:
    ConcreteMediator() {
        c1 = std::make_unique(this);
        c2 = std::make_unique(this);
    }
    void run() { c1->doA(); }
    void notify(Colleague*, const std::string& event) override {
        if (event == "A") {
            std::cout &lt;< "Mediator reacts to A, triggering Component 2...n";
            c2->doB();
        }
    }
};

int main() {
    ConcreteMediator mediator;
    mediator.run();
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod

class Mediator(ABC):
    @abstractmethod
    def notify(self, sender: "Colleague", event: str) -> None:
        pass

class Colleague:
    def __init__(self, mediator: Mediator = None):
        self._mediator = mediator

    @property
    def mediator(self) -> Mediator:
        return self._mediator

    @mediator.setter
    def mediator(self, mediator: Mediator) -> None:
        self._mediator = mediator

class Component1(Colleague):
    def do_a(self) -> None:
        print("Component 1 does A.")
        self.mediator.notify(self, "A")

class Component2(Colleague):
    def do_b(self) -> None:
        print("Component 2 does B.")

class ConcreteMediator(Mediator):
    def __init__(self, comp1: Component1, comp2: Component2):
        self._comp1 = comp1
        self._comp1.mediator = self
        self._comp2 = comp2
        self._comp2.mediator = self

    def notify(self, sender: Colleague, event: str) -> None:
        if event == "A":
            print("Mediator reacts to A and coordinates Component 2...")
            self._comp2.do_b()

if __name__ == "__main__":
    c1 = Component1()
    c2 = Component2()
    mediator = ConcreteMediator(c1, c2)
    c1.do_a()

6. Memento Pattern

History & Origin

The Memento pattern was created to capture and externalize an object’s internal state without violating encapsulation, allowing the object to be restored to this state later. This prevents external caretaker objects from gaining access to the originator’s private internal state representation.

Real-World Industry Use Cases

  • Text Editor History: Storing snapshots of text content to support multi-level undo operations.
  • Database Transactions: Saving checkpoints to roll back failed stateful transactions.
  • Game State Saving: Serializing internal level and inventory states for later restoration.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

class Memento {
private:
    std::string state;
    friend class Originator;
    explicit Memento(std::string s) : state(std::move(s)) {}
    std::string getState() const { return state; }
};

class Originator {
private:
    std::string state;
public:
    void setState(const std::string& s) {
        state = s;
        std::cout &lt;&lt; &quot;Originator: Setting state to &quot;&quot; &lt;&lt; state &lt;&lt; &quot;&quot;n&quot;;
    }
    std::unique_ptr save() {
        return std::unique_ptr(new Memento(state));
    }
    void restore(const Memento& memento) {
        state = memento.getState();
        std::cout &lt;&lt; &quot;Originator: Restored state to &quot;&quot; &lt;&lt; state &lt;< ""n";
    }
};

int main() {
    Originator originator;
    originator.setState("State #1");
    auto memento = originator.save();

    originator.setState("State #2");
    originator.restore(*memento);
    return 0;
}

Production Python Code Implementation

class Memento:
    def __init__(self, state: str):
        self._state = state

    def get_state(self) -> str:
        return self._state

class Originator:
    def __init__(self):
        self._state = ""

    def set_state(self, state: str) -> None:
        print(f"Originator: Setting state to "{state}"")
        self._state = state

    def save(self) -> Memento:
        return Memento(self._state)

    def restore(self, memento: Memento) -> None:
        self._state = memento.get_state()
        print(f"Originator: Restored state to "{self._state}"")

if __name__ == "__main__":
    originator = Originator()
    originator.set_state("State #1")
    memento = originator.save()

    originator.set_state("State #2")
    originator.restore(memento)

7. Observer Pattern

History & Origin

The Observer pattern was developed to establish a one-to-many dependency between objects, ensuring that when the state of one object (the subject) changes, all its dependents (observers) are notified and updated automatically. It replaced resource-intensive polling loops with reactive push semantics.

Real-World Industry Use Cases

  • Event-Driven Pub/Sub Systems: Processing messages asynchronously via queues like Kafka or RabbitMQ.
  • UI Reactivity Engines: Automatically updating UI elements when underlying model state changes (e.g., RxJS or Vue.js).
  • Stock Market Dashboards: Pushing live price feeds to thousands of connected clients in real time.

Production C++ Code Implementation

#include 
#include 
#include 
#include 

class Observer {
public:
    virtual ~Observer() = default;
    virtual void update(float temp) = 0;
};

class Subject {
private:
    std::vector&lt;std::weak_ptr> observers;
    float temperature = 0.0f;
public:
    void registerObserver(const std::shared_ptr& obs) {
        observers.push_back(obs);
    }
    void setTemperature(float temp) {
        temperature = temp;
        notifyObservers();
    }
private:
    void notifyObservers() {
        for (auto it = observers.begin(); it != observers.end();) {
            if (auto obs = it->lock()) {
                obs->update(temperature);
                ++it;
            } else {
                it = observers.erase(it);
            }
        }
    }
};

class Display : public Observer {
public:
    void update(float temp) override {
        std::cout &lt;&lt; &quot;[Display] Temperature update: &quot; &lt;&lt; temp &lt;&lt; &quot; Cn&quot;;
    }
};

int main() {
    auto subject = std::make_unique();
    auto display = std::make_shared();

    subject->registerObserver(display);
    subject->setTemperature(24.5f);
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod
from typing import List
import weakref

class Observer(ABC):
    @abstractmethod
    def update(self, temperature: float) -> None:
        pass

class Subject:
    def __init__(self):
        self._observers: List[weakref.ReferenceType] = []
        self._temperature = 0.0

    def register_observer(self, observer: Observer) -> None:
        self._observers.append(weakref.ref(observer))

    def set_temperature(self, temperature: float) -> None:
        self._temperature = temperature
        self._notify_observers()

    def _notify_observers(self) -> None:
        active_observers = []
        for ref in self._observers:
            obs = ref()
            if obs is not None:
                obs.update(self._temperature)
                active_observers.append(ref)
        self._observers = active_observers

class Display(Observer):
    def update(self, temperature: float) -> None:
        print(f"[Display] Temperature update: {temperature} C")

if __name__ == "__main__":
    subject = Subject()
    display = Display()

    subject.register_observer(display)
    subject.set_temperature(24.5)

8. State Pattern

History & Origin

The State pattern was designed to allow an object to alter its behavior dynamically when its internal state changes. This pattern structures state-dependent code by encapsulating separate states into dedicated classes, eliminating massive, unmaintainable nested switch/if-else conditionals.

Real-World Industry Use Cases

  • TCP Connection Handlers: Managing connection transitions smoothly between LISTEN, ESTABLISHED, and CLOSED states.
  • E-Commerce Order Pipelines: Guiding order processing through PaymentPending, Shipped, and Delivered stages.
  • Vending Machine Controllers: Executing dynamic operational shifts based on inserted coins and selected items.

Production C++ Code Implementation

#include 
#include 

class Context;

class State {
public:
    virtual ~State() = default;
    virtual void handle(Context& context) = 0;
};

class Context {
private:
    std::shared_ptr currentState;
public:
    void transitionTo(std::shared_ptr state) {
        currentState = std::move(state);
    }
    void request() {
        if (currentState) currentState->handle(*this);
    }
};

class StateB : public State {
public:
    void handle(Context&) override {
        std::cout &lt;&lt; &quot;StateB handling request. Final State.n&quot;;
    }
};

class StateA : public State {
public:
    void handle(Context&amp; context) override {
        std::cout &lt;&lt; &quot;StateA handling request. Transitioning to StateB.n&quot;;
        context.transitionTo(std::make_shared());
    }
};

int main() {
    Context context;
    context.transitionTo(std::make_shared());
    context.request();
    context.request();
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod

class State(ABC):
    @abstractmethod
    def handle(self, context: "Context") -> None:
        pass

class Context:
    def __init__(self, state: State):
        self._state = state

    def transition_to(self, state: State) -> None:
        self._state = state

    def request(self) -> None:
        self._state.handle(self)

class StateB(State):
    def handle(self, context: Context) -> None:
        print("StateB handling request. Final State.")

class StateA(State):
    def handle(self, context: Context) -> None:
        print("StateA handling request. Transitioning to StateB.")
        context.transition_to(StateB())

if __name__ == "__main__":
    context = Context(StateA())
    context.request()
    context.request()

9. Strategy Pattern

History & Origin

The Strategy pattern was developed to define a family of algorithms, encapsulate each one, and make them interchangeable at runtime. It decouples the selection of an algorithm from the client code that uses it, enabling flexible, runtime behavioral configuration.

Real-World Industry Use Cases

  • Payment Gateway Routing: Choosing between Stripe, PayPal, and Apple Pay dynamically at checkout.
  • Compression Tools: Compressing files dynamically using GZIP, ZIP, or TAR algorithms.
  • Routing Engines: Calculating navigation paths based on user preferences (e.g., fastest route vs. avoiding tolls).

Production C++ Code Implementation

#include 
#include 

class Strategy {
public:
    virtual ~Strategy() = default;
    virtual void execute() const = 0;
};

class StrategyA : public Strategy {
public:
    void execute() const override {
        std::cout &lt;&lt; &quot;Executing algorithm strategy A.n&quot;;
    }
};

class StrategyB : public Strategy {
public:
    void execute() const override {
        std::cout &lt;&lt; &quot;Executing algorithm strategy B.n&quot;;
    }
};

class Context {
private:
    std::shared_ptr strategy;
public:
    void setStrategy(std::shared_ptr strat) {
        strategy = std::move(strat);
    }
    void executeStrategy() const {
        if (strategy) strategy->execute();
    }
};

int main() {
    Context context;
    context.setStrategy(std::make_shared());
    context.executeStrategy();

    context.setStrategy(std::make_shared());
    context.executeStrategy();
    return 0;
}

Production Python Code Implementation

from typing import Callable

class Context:
    def __init__(self, strategy: Callable[[], None]):
        self._strategy = strategy

    def set_strategy(self, strategy: Callable[[], None]) -> None:
        self._strategy = strategy

    def execute_strategy(self) -> None:
        self._strategy()

def strategy_a() -> None:
    print("Executing algorithm strategy A.")

def strategy_b() -> None:
    print("Executing algorithm strategy B.")

if __name__ == "__main__":
    context = Context(strategy_a)
    context.execute_strategy()

    context.set_strategy(strategy_b)
    context.execute_strategy()

10. Template Method Pattern

History & Origin

The Template Method pattern defines the high-level skeleton of an algorithm in a base class, deferring some intermediate execution steps to subclasses. This allows subclasses to redefine specific steps of an algorithm without altering its overall structural flow.

Real-World Industry Use Cases

  • ETL Data Pipelines: Standardizing core pipeline stages (Extract, Transform, Load) while letting subclasses customize data formats.
  • Document Generation: Orchestrating document export phases (Header, Body, Footer) for CSV, PDF, or HTML files.
  • Test Lifecycles: Controlling execution phases (setup, run, teardown) in testing frameworks.

Production C++ Code Implementation

#include 

class DataPipeline {
public:
    virtual ~DataPipeline() = default;
    void run() {
        readData();
        processData();
        writeData();
    }
protected:
    virtual void readData() = 0;
    void processData() {
        std::cout &lt;&lt; &quot;Processing data...n&quot;;
    }
    virtual void writeData() = 0;
};

class CSVDataPipeline : public DataPipeline {
protected:
    void readData() override {
        std::cout &lt;&lt; &quot;Extracting data from CSV file.n&quot;;
    }
    void writeData() override {
        std::cout &lt;< "Loading data into SQL database.n";
    }
};

int main() {
    CSVDataPipeline pipeline;
    pipeline.run();
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod

class DataPipeline(ABC):
    def run(self) -> None:
        self._read_data()
        self._process_data()
        self._write_data()

    @abstractmethod
    def _read_data(self) -> None:
        pass

    def _process_data(self) -> None:
        print("Processing data...")

    @abstractmethod
    def _write_data(self) -> None:
        pass

class CSVDataPipeline(DataPipeline):
    def _read_data(self) -> None:
        print("Extracting data from CSV file.")

    def _write_data(self) -> None:
        print("Loading data into SQL database.")

if __name__ == "__main__":
    pipeline = CSVDataPipeline()
    pipeline.run()

11. Visitor Pattern

History & Origin

The Visitor pattern separates algorithms from the object structures on which they operate, allowing developers to add new operations to existing class hierarchies without modifying their code. It utilizes double-dispatch mechanics to determine the correct execution logic at runtime.

Real-World Industry Use Cases

  • AST Code Generators: Executing different code generation logic across compiler parse trees.
  • Shopping Cart Checkout: Applying dynamic tax, shipping, and discount rules across varied product types.
  • Document Export Engines: Exporting complex composite document structures into PDF, Markdown, or HTML formats.

Production C++ Code Implementation

#include 
#include 
#include 

class ConcreteElementA;
class ConcreteElementB;

class Visitor {
public:
    virtual ~Visitor() = default;
    virtual void visit(const ConcreteElementA& el) = 0;
    virtual void visit(const ConcreteElementB& el) = 0;
};

class Element {
public:
    virtual ~Element() = default;
    virtual void accept(Visitor& visitor) const = 0;
};

class ConcreteElementA : public Element {
public:
    void accept(Visitor& visitor) const override { visitor.visit(*this); }
    std::string getElementAName() const { return "ElementA"; }
};

class ConcreteElementB : public Element {
public:
    void accept(Visitor& visitor) const override { visitor.visit(*this); }
    std::string getElementBName() const { return "ElementB"; }
};

class ConcreteVisitor : public Visitor {
public:
    void visit(const ConcreteElementA& el) override {
        std::cout &lt;&lt; &quot;Visitor processing &quot; &lt;&lt; el.getElementAName() &lt;&lt; &quot;n&quot;;
    }
    void visit(const ConcreteElementB&amp; el) override {
        std::cout &lt;&lt; &quot;Visitor processing &quot; &lt;&lt; el.getElementBName() &lt;&lt; &quot;n&quot;;
    }
};

int main() {
    std::vector&lt;std::unique_ptr> elements;
    elements.push_back(std::make_unique());
    elements.push_back(std::make_unique());

    ConcreteVisitor visitor;
    for (const auto& el : elements) {
        el->accept(visitor);
    }
    return 0;
}

Production Python Code Implementation

from abc import ABC, abstractmethod
from typing import List

class Element(ABC):
    @abstractmethod
    def accept(self, visitor: "Visitor") -> None:
        pass

class ConcreteElementA(Element):
    def accept(self, visitor: "Visitor") -> None:
        visitor.visit_concrete_element_a(self)

    def get_element_a_name(self) -> str:
        return "ElementA"

class ConcreteElementB(Element):
    def accept(self, visitor: "Visitor") -> None:
        visitor.visit_concrete_element_b(self)

    def get_element_b_name(self) -> str:
        return "ElementB"

class Visitor(ABC):
    @abstractmethod
    def visit_concrete_element_a(self, el: ConcreteElementA) -> None:
        pass

    @abstractmethod
    def visit_concrete_element_b(self, el: ConcreteElementB) -> None:
        pass

class ConcreteVisitor(Visitor):
    def visit_concrete_element_a(self, el: ConcreteElementA) -> None:
        print(f"Visitor processing {el.get_element_a_name()}")

    def visit_concrete_element_b(self, el: ConcreteElementB) -> None:
        print(f"Visitor processing {el.get_element_b_name()}")

if __name__ == "__main__":
    elements: List[Element] = [ConcreteElementA(), ConcreteElementB()]
    visitor = ConcreteVisitor()

    for el in elements:
        el.accept(visitor)

Production C++ and Python Code Implementations

Implementing behavioral design patterns in C++ requires careful attention to object lifetimes, reference ownership, and performance. Modern C++ (C++11 and beyond) has moved away from raw pointers and manual memory management toward smart pointers such as std::unique_ptr and std::shared_ptr. Using smart pointers ensures exception safety and prevents resource leaks. Additionally, techniques like template programming and std::variant (introduced in C++17) allow developers to write highly optimized, compile-time polymorphs that bypass the runtime overhead of traditional virtual method tables.

In contrast, Python embraces runtime dynamic typing, first-class functions, and built-in duck typing protocols, allowing developers to write highly expressive code with minimal overhead. Since functions in Python are first-class objects, complex structures like the Strategy or Command patterns can often be simplified into simple, passing callables. Utilizing native language features such as standard decorators, dynamic attributes, and magic methods (e.g., __iter__ or __call__) enables developers to write idiomatic Python code that remains highly readable and maintainable.

When choosing between C++ and Python for production systems, architects must evaluate the system’s performance and safety constraints. C++ is ideal for low-latency systems (such as financial trading platforms, gaming engines, and real-time processing pipelines) where deterministic memory management and predictable execution speeds are paramount. Python is the preferred choice for rapid application development, data science, web services, and automation pipelines, where developer productivity and fast iteration cycles are prioritized over raw hardware optimization.

System Design Roadmaps and Key Developer Resources

Mastering behavioral design patterns is a vital milestone in preparing for senior low-level design (LLD) and system architecture interviews. Engineers must understand that design patterns are not silver bullets; applying them prematurely can lead to over-engineered, overly complex, and difficult-to-maintain codebases. The key is to first identify the primary axes of change within your system, and then selectively apply the appropriate patterns to decouple and protect those volatile boundaries. Engineers looking for top-tier opportunities to apply these architectural skills can explore the curated listings on our job platform at Hire Alert Jobs.

These low-level design patterns scale naturally to solve macro-level system architecture challenges. For example, the Observer pattern serves as the foundation for event-driven publish-subscribe microservices, while the State pattern mirrors the distributed saga workflow engines used to manage multi-service transactions. Bridging the gap between class-level contracts and service-level components allows architects to construct highly cohesive, decoupled systems where the low-level code structure naturally reflects the high-level system topology.

To continuously improve your low-level design skills, we recommend regularly reviewing open-source codebases, participating in architectural reviews, and practicing refactoring legacy code to resolve structural bottlenecks. Engaging with structured study guides, interactive mock interviews, and technical discussion forums will help you stay up to date with modern design paradigms. Over time, this disciplined approach will help you build the intuition needed to select and implement the right design patterns for complex, large-scale systems.

Key Educational Resource & System Design Roadmap

Before analyzing raw code blocks and practicing object-oriented structures, watch this masterclass design pattern video guide:
https://youtu.be/XDIysqu7S5o

Follow our YouTube Channels for Coding Concepts & Architecture:

Join Our Technical Communities for Daily Study Guides & Alerts:

Deep-Dive DSA & Coding Reference Guide:

⚠️ SYSTEM METADATA SECTION (Hidden from website view, visible to SEO engines):
Keywords: Behavioral Design Patterns C++, Behavioral Design Patterns Python, Strategy Observer Code Examples, Low Level Design Behavioral Guide
Tags: Behavioral Design Patterns, Design Patterns, Chain of Responsibility, Command Pattern, Interpreter Pattern, Iterator Pattern, Mediator Pattern, Memento Pattern, Observer Pattern, State Pattern, Strategy Pattern, Template Method, Visitor Pattern, Object Communication, C++ Behavioral Patterns, Python Behavioral Patterns, Object Oriented Programming, OOP Behavioral, Production C++ Code, Pythonic Code, Low Level Design, LLD Behavioral, Coding Interview Prep, Technical Interview Questions, Backend Architecture, System Design, Clean Code, Event Driven Architecture, State Management, Strategy Pattern C++, Observer Pattern Python, Command Pattern Example, Template Method Pattern, Visitor Pattern Code, Loose Coupling, Messaging Patterns, Notification Systems, Daily Study Guide, VS Coding Academy, Trendy VS Vlogs, Hire Alert Jobs, Love2Pickleball Jobs, Software Engineering Placements, Programming Reference Guide, Gang of Four, GoF Behavioral, Code Flexibility, Systems Architect Prep, Advanced Programming Concepts, Developer Training

Mastering behavioral design patterns in C++ and Python is a transformative step for any software engineer transitioning from a programmer to a system architect. By understanding the historical context, execution semantics, and implementation nuances of these eleven patterns, you can design highly resilient, maintainable, and decoupled systems. Whether optimizing high-performance C++ pipelines or building rapid, elegant Python services, these tools will empower you to solve complex architectural challenges with confidence. Continue practicing, analyzing production codebases, and applying these strategies to elevate your low-level system designs to industry-grade standards.

Mastering Behavioral Design Patterns in C++ and Python: The Ultimate Low-Level Design Guide

HSBC Hiring Manager Data and Analytics India

Leave a Comment