Lesson 00: Understanding Design Patterns

Why Do We Need Design Patterns?

1.1 The Problem in Real-World C++ Software Development

As C++ systems scale in size and complexity (e.g., embedded firmware, GUI frameworks, game engines, distributed systems), developers face recurring architectural challenges:

• Tight coupling between classes
• Code duplication
• Rigid system structures
• Poor maintainability
• Difficulty extending features
• Hard-to-test modules

These issues are not language problems — they are design problems.

Design patterns provide proven architectural solutions to recurring design challenges.

class MySQLDatabase {
public:
    void connect() {}
    void query(const std::string& sql) {}
};

class UserService {
private:
    MySQLDatabase db;  // Direct dependency

public:
    void registerUser() {
        db.connect();
        db.query("INSERT INTO users...");
    }
};

double calculateDiscountVIP(double price) {
    return price * 0.8;
}

double calculateDiscountEmployee(double price) {
    return price * 0.8;
}

class Report {
public:
    void generatePDF();
    void generateHTML();
    void generateExcel();
};

class OrderManager {
public:
    void process() {
        // 2000 lines of mixed logic:
        // DB operations
        // UI logic
        // Business rules
        // Logging
        // Validation
    }
};

class PaymentProcessor {
public:
    void processPayment(std::string type) {
        if (type == "CreditCard") {
            // handle credit
        }
        else if (type == "PayPal") {
            // handle paypal
        }
        else if (type == "Bitcoin") {
            // handle bitcoin
        }
    }
};

class FileLogger {
public:
    void log(const std::string& message) {
        std::ofstream file("log.txt");
        file << message;
    }
};

class OrderService {
private:
    FileLogger logger;

public:
    void processOrder() {
        logger.log("Processing order");
    }
};

1.2 Definition of a Design Pattern

A design pattern is:

A reusable, generalized solution to a commonly occurring problem within a given context in software design.

Design patterns are not code templates, and they are not libraries. They are structured design blueprints.

They describe:

• Intent
• Structure
• Roles of participating classes
• Collaboration mechanism
• Consequences

1.3 Historical Context

The concept was popularized in:

• "Design Patterns: Elements of Reusable Object-Oriented Software"
• Authors: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
• Commonly referred to as the Gang of Four (GoF)

They categorized patterns into:

1. Creational Patterns
2. Structural Patterns
3. Behavioral Patterns

1.4 Why C++ Especially Benefits from Design Patterns

C++ provides:

• Manual memory management
• Multiple inheritance
• Templates (generic programming)
• Polymorphism
• Resource Acquisition Is Initialization (RAII)
• Move semantics

These powerful tools increase flexibility — but also complexity.

Design patterns help:

• Structure object relationships
• Manage lifetime properly
• Avoid memory leaks
• Reduce ownership ambiguity
• Separate interface from implementation
• Encapsulate variability

In modern C++ (C++11–C++23), patterns integrate with:

• Smart pointers (std::unique_ptr, std::shared_ptr)
• Move semantics
• Lambda expressions
• Template metaprogramming
• std::function

Advantages and Disadvantages of Design Patterns

2.1 Advantages

1. Proven Solutions

Patterns are battle-tested across decades of production systems.

They reduce trial-and-error design.

2. Improves Code Reusability

Patterns promote:

1. Low coupling
2. High cohesion
3. Encapsulation of change

This enables modular design.

3. Improves Maintainability

By separating concerns:

• Business logic
• Object creation
• Communication
• Responsibilities

Example: Factory Pattern separates object creation from usage.

4. Enhances Communication Between Developers

Patterns create a shared vocabulary:

Instead of explaining architecture in detail:

“We use Observer for event handling.”

The entire structure becomes clear immediately.

5. Supports Open-Closed Principle (OCP)

Most patterns aim to:

Allow extension without modifying existing code.

This is essential for scalable systems.

2.2 Disadvantages

1. Overengineering

Using patterns where a simple design is sufficient increases:

• Complexity
• Indirection
• Maintenance cost

“Not every problem requires a pattern.”

2. Increased Abstraction

Patterns often introduce:

• Interfaces
• Base classes
• Indirection layers

This may reduce readability for beginners.

3. Performance Overhead

Some patterns are introduced:

• Virtual function calls
• Heap allocations
• Additional indirection

In high-performance systems (e.g., embedded systems), this must be evaluated carefully.

4. Misapplication

Incorrect pattern choice may:

• Increase coupling
• Reduce clarity
• Make debugging harder

Pattern usage requires understanding the problem context.

How Do Design Patterns Work?

3.1 Core Concept of a Pattern

Every design pattern contains:

• Intent – What problem does it solve?
• Structure – Class relationships
• Participants – Roles of classes
• Collaboration – How objects interact
• Consequences – Trade-offs

3.2 Core Idea Behind Patterns

Patterns typically address one of three design dimensions:

class Singleton {
public:
    static Singleton& getInstance() {
        static Singleton instance;  // Guaranteed thread-safe since C++11
        return instance;
    }

    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

private:
    Singleton() {}
};

Circle c;

Shape* shape = ShapeFactory::createShape("Circle");

3.3 The Real Core: Decoupling

At a deeper level, most patterns aim to:

Reduce coupling while preserving flexibility.

Patterns manage:

• Object ownership
• Responsibility assignment
• Dependency direction
• Variation points

They introduce indirection where necessary.

3.4 Patterns and SOLID Principles

Design patterns operationalize SOLID principles:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Patterns are practical implementations of these principles.

3.5 When to Use a Pattern

Use a pattern when:

• You recognize a recurring design problem
• Code smells appear (rigidity, fragility, immobility)
• You anticipate change in specific dimensions
• Responsibility allocation becomes unclear

Do NOT use a pattern:

• Just to show knowledge
• When simple composition solves the problem
• When requirements are trivial

Summary of Lesson 1

Design patterns:

• Are reusable design solutions
• Improve maintainability and scalability
• Provide shared architectural vocabulary
• Must be applied with contextual judgment

Core idea:

Patterns manage object relationships and responsibilities to reduce coupling and increase flexibility.

Design Pattern Categories

Design patterns are traditionally grouped into three primary categories based on what aspect of software design they address:

• Object creation
• Object composition
• Object interaction

Understanding these categories helps developers choose the correct architectural strategy for a given design problem.

Introducing a Design Pattern in C++

Applying a design pattern in C++ should follow a disciplined engineering process rather than mechanical imitation.

5.1 General Implementation Steps

Step 1: Identify a Recurring Design Problem

Recognize symptoms such as:

• Tight coupling
• Large conditional structures
• Code duplication
• Difficulty extending functionality
• Complex object creation
• Patterns should solve actual design friction, not theoretical concerns.

Step 2: Abstract the Core Concept

Determine:

• What varies?
• What remains stable?
• Where is the dependency?
• Who owns responsibility?

Define clear abstractions (interfaces or base classes).

Step 3: Draw a UML Diagram

Visualize:

• Class hierarchy
• Relationships (inheritance, composition)
• Object collaboration

This prevents implementation errors before coding.

Step 4: Implement in C++

Translate design into C++ using:

• Abstract base classes
• Virtual functions
• Smart pointers
• RAII principles
• Dependency injection where appropriate

Avoid overusing raw pointers unless ownership semantics are clear.

Step 5: Test and Analyze

Evaluate:

• Is coupling reduced?
• Is extensibility improved?
• Did complexity decrease or increase?
• Are unit tests easier to write?

Patterns should improve architecture — not complicate it.

Deciding Whether a Pattern Is Appropriate

Not every design issue requires a design pattern.

Before applying one, ask:

• Is this problem recurring?
• Is the complexity structural or temporary?
• Will the system grow in this dimension?
• Does the solution increase abstraction unnecessarily?

Warning: Avoid Over-Engineering

Misusing patterns can lead to:

• Excessive abstraction layers
• Unnecessary inheritance hierarchies
• Reduced readability
• Performance overhead
• Increased cognitive load

Common mistake:

Implementing a pattern simply because it is known — not because it is needed.

Engineering Guideline

Use patterns when:

• The system shows clear architectural stress.
• Flexibility and extension are foreseeable requirements.
• The design problem aligns with the pattern's intent.

Avoid patterns when:

• A simple function or class solves the problem.
• Requirements are small and unlikely to change.
• The abstraction cost exceeds the benefit.