1 Design Patterns - Comprehensive Guide

Generated: Tue Feb 3 17:15:34 UTC 2026

2 Design Patterns in Java — Practical, Runnable Examples

A curated, production-oriented collection of classic software design patterns implemented in Java.
Each pattern is expressed as small, focused, runnable code intended to demonstrate intent, structure, and trade-offs — not just theory.

This repository is designed as a long-term reference for backend engineers, architects, and senior developers.

2.1 🎯 Objectives

• Provide clear, minimal implementations of well-known design patterns
• Emphasize when to use vs. when to avoid each pattern
• Encourage good architectural judgment, not pattern overuse
• Serve as a reference companion for real-world system design

2.2 🧠 Who This Is For

• Backend engineers (Java / JVM ecosystem)
• Software architects and technical leads
• Developers preparing for system design interviews
• Anyone who wants practical pattern fluency, not just definitions

2.3 🛠 Tech Stack

• Language: Java (21+)
• Build Tool: Maven
• Paradigm: Object-Oriented Design
• Testing: JUnit (where applicable)

2.4 🚀 Quick Start

2.4.1 Prerequisites

• Java 21+
• Maven 3.8+

2.4.2 Build & Test

mvn clean test

2.4.3 Import into IDE

Open the project as a Maven project using pom.xml in IntelliJ IDEA or Eclipse.

2.5 📚 Pattern Index

2.5.1 Creational Patterns

2.5.2 Structural Patterns

2.5.3 Behavioral Patterns

2.5.4 Hybrid / Reference Patterns

• Finite State Machine — state-machine/
• Pipes & Filters — pipes-and-filters/
• Service Locator — service-locator/
• Double-Checked Locking — double-checked-locking/
• Method Object — method-object/

2.6 🧩 How to Read Each Pattern

For each pattern folder, focus on:

1. Intent — what problem is being solved
2. Roles — participants and responsibilities
3. Trade-offs — costs vs. benefits
4. Alternatives — simpler options to consider

Patterns are tools, not goals. Overuse is a design smell.

2.7 🧪 Testing Philosophy

• Patterns that demonstrate behavior include unit tests
• Tests focus on observable behavior, not implementation details
• Examples remain intentionally small and readable

2.8 🧭 Design Principles Emphasized

• SOLID principles
• Composition over inheritance
• Separation of concerns
• Dependency inversion
• Explicit design trade-offs

2.9 🛣 Roadmap

• Add a short README.md inside each pattern folder
• Add UML-style diagrams (Mermaid) per pattern
• Add pattern comparison guide (e.g. Strategy vs State vs Command)
• Enforce formatting & static analysis
• Publish tagged releases (v1.x)

2.10 🤝 Contributing

Contributions are welcome and encouraged!

• Improved examples with clearer intent
• Additional tests that demonstrate behavior
• Documentation clarifications
• New patterns with justification

see CONTRIBUTING.md for details.

2.11 📜 License

2.12 This project is licensed under the MIT License — free to use, modify, and distribute.

3 Abstract Factory Pattern

3.1 📋 Overview

The Abstract Factory pattern - Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

3.2 🎯 Intent

Problem Solved:

• You need to create families of related objects while ensuring they work together correctly; switch between families without modifying client code.

Use When:

• Your system needs multiple families of related products
• Ensure only compatible family members are used
• Switch between product families dynamically

3.3 👥 Roles & Responsibilities

3.4 💡 Code Example

// Abstract Factory
public interface KingdomFactory {
    Castle createCastle();
    King createKing();
    Army createArmy();
}

// Concrete Factories
public class ElfKingdomFactory implements KingdomFactory {
    public Castle createCastle() { return new ElfCastle(); }
    public King createKing() { return new ElfKing(); }
    public Army createArmy() { return new ElfArmy(); }
}

public class DwarfKingdomFactory implements KingdomFactory {
    public Castle createCastle() { return new DwarfCastle(); }
    public King createKing() { return new DwarfKing(); }
    public Army createArmy() { return new DwarfArmy(); }
}

// Usage
KingdomFactory factory = new ElfKingdomFactory();
Castle castle = factory.createCastle();

Reasoning: Client code doesn’t know concrete classes. Entire family changes by swapping factory. Ensures type-safe product combinations.

3.5 🔀 Design Principles

• Dependency Inversion
• Single Responsibility
• Open/Closed Principle

3.6 📊 Class Diagram

classDiagram
    class Client
    class AbstractFactory {
        <<interface>>
        +createProductA()
        +createProductB()
    }
    class ConcreteFactory1
    class ConcreteFactory2
    class AbstractProductA {
        <<interface>>
    }
    class AbstractProductB {
        <<interface>>
    }
    class ProductA1
    class ProductA2
    class ProductB1
    class ProductB2
    AbstractFactory <|-- ConcreteFactory1
    AbstractFactory <|-- ConcreteFactory2
    AbstractProductA <|-- ProductA1
    AbstractProductA <|-- ProductA2
    AbstractProductB <|-- ProductB1
    AbstractProductB <|-- ProductB2
    ConcreteFactory1 --> ProductA1
    ConcreteFactory1 --> ProductB1
    ConcreteFactory2 --> ProductA2
    ConcreteFactory2 --> ProductB2
    AbstractFactory --> AbstractProductA
    AbstractFactory --> AbstractProductB
    Client --> AbstractFactory
    Client --> AbstractProductA
    Client --> AbstractProductB

3.7 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>AbstractFactory: createProductA()
    AbstractFactory-->>Client: AbstractProductA
    Client->>AbstractFactory: createProductB()
    AbstractFactory-->>Client: AbstractProductB
    Client->>AbstractProductA: use()
    Client->>AbstractProductB: use()

3.8 ⚖️ Trade-offs

3.8.1 Advantages ✅

• Isolates client from concrete classes
• Ensures consistency among related products
• Easy to swap product families
• Centralizes product creation logic

3.8.2 Disadvantages ❌

• More interfaces/classes required
• Complex hierarchy
• Adding new product type affects all factories
• Overkill for simple scenarios

3.9 🚫 When NOT to Use

• When simpler solutions suffice
• When adding unnecessary complexity
• In performance-critical paths (if it introduces overhead)

3.10 ⚠️ Common Anti-Patterns

3.11 🌍 Real-World Use Cases

• Swing/AWT UI frameworks
• Database drivers (MySQL, Postgres)
• Cross-platform theme factories
• Java Collections framework factories

3.12 🔗 Alternatives & Similar Patterns

3.13 📝 Best Practices

1. Keep the pattern simple and focused
2. Document pattern usage in code
3. Avoid overusing patterns
4. Test pattern implementations thoroughly
5. Consider performance implications
6. Make patterns explicit in architecture
7. Provide clear examples
8. Review patterns periodically

3.14 🎓 Related Patterns

• Gang of Four patterns
• Enterprise Integration Patterns
• Architectural Patterns

3.15 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru Design Patterns

4 Adapter Pattern

4.1 📋 Overview

This folder contains the Adapter design pattern implementation.

4.2 🎯 Intent

The adapter pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

4.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

4.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

4.5 📊 Class Diagram

classDiagram
    class Client
    class Target {
        <<interface>>
        +request()
    }
    class Adapter {
        +request()
    }
    class Adaptee {
        +specificRequest()
    }
    Client --> Target
    Target <|-- Adapter
    Adapter --> Adaptee

4.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Target: request()
    Target->>Adapter: request()
    Adapter->>Adaptee: specificRequest()
    Adaptee-->>Adapter: result
    Adapter-->>Client: result

4.7 ⚖️ Trade-offs

4.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

4.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

4.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

4.9 ⚠️ Common Anti-Patterns

4.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

4.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

4.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

4.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

5 Bridge Pattern

5.1 📋 Overview

This folder contains the Bridge design pattern implementation.

5.2 🎯 Intent

The bridge pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

5.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

5.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

5.5 📊 Class Diagram

classDiagram
    class Client
    class Abstraction {
        -implementor: Implementor
        +operation()
    }
    class RefinedAbstraction
    class Implementor {
        <<interface>>
        +operationImpl()
    }
    class ConcreteImplementorA
    class ConcreteImplementorB
    Client --> Abstraction
    Abstraction <|-- RefinedAbstraction
    Implementor <|-- ConcreteImplementorA
    Implementor <|-- ConcreteImplementorB
    Abstraction --> Implementor

5.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Abstraction: operation()
    Abstraction->>Implementor: operationImpl()
    Implementor-->>Abstraction: result
    Abstraction-->>Client: result

5.7 ⚖️ Trade-offs

5.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

5.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

5.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

5.9 ⚠️ Common Anti-Patterns

5.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

5.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

5.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

5.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

6 Builder Pattern

6.1 📋 Overview

The Builder Pattern is a creational pattern that constructs complex objects step-by-step, separating the construction logic from the representation. It provides a fluent, readable interface for building objects with many optional parameters or complex initialization logic.

6.2 🎯 Intent

Problem Solved: - Creating objects with many parameters is error-prone and produces unreadable code - Objects have optional and mandatory parameters; telescoping constructors become unwieldy - Complex initialization logic should be separated from object representation - You need to construct immutable objects while maintaining readability

Use When: - Objects have 3+ optional parameters - You need to build immutable objects with validation - Construction logic is complex or multi-step - You want to improve code readability over constructor overloading

6.3 👥 Roles & Responsibilities

Key Characteristics: - Fluent interface enabling method chaining - Separation of construction from representation - Step-by-step object assembly - Validation at build stage

6.4 💡 Implementation Example

// Product: Complex object to build
public class Hero {
    private final String name;
    private final Profession profession;
    private final HairType hairType;
    private final HairColor hairColor;
    private final Armor armor;
    private final Weapon weapon;

    private Hero(HeroBuilder builder) {
        this.name = builder.name;
        this.profession = builder.profession;
        this.hairType = builder.hairType;
        this.hairColor = builder.hairColor;
        this.armor = builder.armor;
        this.weapon = builder.weapon;
    }

    // Builder: Inner class managing construction
    public static class HeroBuilder {
        private final String name;
        private final Profession profession;
        private HairType hairType;
        private HairColor hairColor;
        private Armor armor;
        private Weapon weapon;

        // Mandatory parameters in constructor
        public HeroBuilder(Profession profession, String name) {
            this.profession = profession;
            this.name = name;
        }

        // Fluent methods for optional parameters
        public HeroBuilder withHairType(HairType hairType) {
            this.hairType = hairType;
            return this;
        }

        public HeroBuilder withHairColor(HairColor hairColor) {
            this.hairColor = hairColor;
            return this;
        }

        public HeroBuilder withArmor(Armor armor) {
            this.armor = armor;
            return this;
        }

        public HeroBuilder withWeapon(Weapon weapon) {
            this.weapon = weapon;
            return this;
        }

        // Build: Final step returning the constructed product
        public Hero build() {
            return new Hero(this);
        }
    }
}

// Usage: Clean, readable, chainable construction
Hero mage = new Hero.HeroBuilder(Profession.MAGE, "Merlin")
    .withHairColor(HairColor.BLACK)
    .withWeapon(Weapon.STAFF)
    .build();

Reasoning: - Separates object construction from its representation - Fluent interface improves readability dramatically - Mandatory parameters enforced in constructor - Optional parameters via fluent methods - Immutability achieved through private constructor

6.5 📊 Class Diagram

classDiagram
    class Client
    class Director {
        -builder: Builder
        +construct()
    }
    class Builder {
        <<interface>>
        +buildPartA()
        +buildPartB()
        +getResult()
    }
    class ConcreteBuilder
    class Product
    Client --> Director
    Director --> Builder
    Builder <|-- ConcreteBuilder
    ConcreteBuilder --> Product

6.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Director: construct()
    Director->>Builder: buildPartA()
    Director->>Builder: buildPartB()
    Builder-->>Director: done
    Client->>Builder: getResult()
    Builder-->>Client: Product

6.7 🔀 Design Principles Emphasized

6.8 ⚖️ Trade-offs

6.8.1 Advantages ✅

• Improved Readability: Fluent interface makes code self-documenting
• Flexibility: Easy to add/remove optional parameters without breaking code
• Immutability: Separating construction enables creation of immutable objects
• Complex Initialization: Handles multi-step construction elegantly
• Mandatory Parameter Enforcement: Constructor ensures required params are present
• Validation: Can validate at build stage before creating object

6.8.2 Disadvantages ❌

• Code Verbosity: More classes and methods to maintain
• Performance Overhead: Creating builder object adds memory/GC pressure
• Complexity for Simple Objects: Overkill for objects with few parameters
• Thread Safety: Builder itself is not thread-safe; don’t share across threads
• Builder Proliferation: Every complex class needs its own builder

6.9 🚫 When NOT to Use

6.10 ⚠️ Common Anti-Patterns & Misuses

6.11 🌍 Real-World Use Cases

6.11.1 Java StringBuilder

// StringBuilder is a builder for immutable String
String text = new StringBuilder()
    .append("Hello")
    .append(" ")
    .append("World")
    .toString();

6.11.2 Google Guava - ImmutableList

// Guava uses builder for complex immutable collections
ImmutableList<String> list = ImmutableList.builder()
    .add("item1")
    .add("item2")
    .build();

6.11.3 Lombok @Builder

// Lombok annotation auto-generates builder
@Builder
public class User {
    private String name;
    private String email;
    private int age;
}

// Usage
User user = User.builder()
    .name("Alice")
    .email("alice@example.com")
    .age(30)
    .build();

6.11.4 HTTP Clients (OkHttp)

// OkHttp Request builder
Request request = new Request.Builder()
    .url("https://example.com")
    .addHeader("User-Agent", "MyApp")
    .post(body)
    .build();

6.11.5 Apache Commons - Configuration

// Configuration builder with fluent interface
Configuration config = new Configuration.Builder()
    .setDatabaseUrl("jdbc:mysql://localhost")
    .setMaxConnections(50)
    .setReadTimeout(5000)
    .build();

6.12 🔗 Alternatives & Similar Patterns

6.13 📝 Best Practices

1. Enforce Mandatory Parameters: Place required params in builder constructor
2. Use Method Chaining: Return this for fluent interface
3. Validate in Build: Check constraints before creating product
4. Keep Builder Simple: Avoid complex logic; delegate to product
5. Consider Lombok: Use @Builder annotation to auto-generate builder code
6. Make Product Immutable: Private constructor, final fields
7. Document Optional Parameters: Clarify defaults and constraints
8. Provide Copy Constructor: Allow building new instance from existing product

6.14 🎓 Related Patterns

• Factory Pattern: Can be used within builder to create complex sub-objects
• Composite Pattern: Builder often used to construct composite structures
• Strategy Pattern: Builder can use different strategies for object construction
• Template Method: Builder steps can follow a template structure

6.15 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch) - Item 2: Builder Pattern
• Google Guava Library
• Lombok @Builder Annotation

7 Chain of Responsibility Pattern

7.1 📋 Overview

The Chain of Responsibility pattern passes a request along a chain of handlers. Each handler decides either to process the request or pass it to the next handler in the chain.

7.2 🎯 Intent

Problem Solved: - You need to process a request by multiple handlers without knowing which handler will process it in advance - You want to decouple the sender of a request from its receiver - You want to allow adding/removing handlers dynamically

Use When: - Multiple objects may handle a request - You don’t know in advance which object should handle the request - You want to issue a request to multiple handlers without specifying the receiver explicitly

7.3 👥 Roles & Responsibilities

7.4 💡 Code Example

public abstract class RequestHandler {
    protected RequestHandler nextHandler;
    
    public void setNextHandler(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }
    
    public abstract void handleRequest(Request request);
}

public class ConcreteHandler extends RequestHandler {
    @Override
    public void handleRequest(Request request) {
        if (canHandle(request)) {
            process(request);
        } else if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
    
    private boolean canHandle(Request request) {
        return request.getType() == RequestType.TYPE_A;
    }
    
    private void process(Request request) {
        System.out.println("Processing request: " + request);
    }
}

// Usage
RequestHandler handler1 = new ConcreteHandler();
RequestHandler handler2 = new ConcreteHandler();
handler1.setNextHandler(handler2);
handler1.handleRequest(new Request(RequestType.TYPE_A));

Reasoning: Decouples sender from receiver; handlers decide whether to handle or pass on request dynamically.

7.5 🔀 Design Principles

• Dependency Inversion Principle
• Single Responsibility Principle
• Open/Closed Principle

7.6 📊 Class Diagram

classDiagram
    class Client
    class Request
    class Handler {
        <<abstract>>
        -next: Handler
        +setNext(h: Handler)
        +handle(r: Request)
    }
    class ConcreteHandlerA
    class ConcreteHandlerB
    Client --> Handler
    Handler <|-- ConcreteHandlerA
    Handler <|-- ConcreteHandlerB
    Handler --> Handler

7.7 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>HandlerA: handle(request)
    alt canHandle
        HandlerA-->>Client: handled
    else pass
        HandlerA->>HandlerB: handle(request)
        HandlerB-->>Client: handled
    end

7.8 ⚖️ Trade-offs

7.8.1 Advantages ✅

• Decouples sender from receiver
• Dynamic handler assignment
• Easy to add/remove handlers
• Multiple handlers can process request
• Flexible request handling

7.8.2 Disadvantages ❌

• Request may not be handled
• Debugging difficult with long chains
• Performance impact with many handlers
• Chain configuration complexity
• Potential circular references

7.9 🚫 When NOT to Use

• Simple sequential processing
• One handler always handles the request
• Performance-critical applications
• Clear handler hierarchy exists

7.10 ⚠️ Common Anti-Patterns

7.11 🌍 Real-World Use Cases

• Event handling in GUI frameworks
• Exception handling in Java
• Servlet filters in web frameworks
• Logging frameworks with appender chains
• Authorization/authentication pipelines

7.12 📝 Best Practices

1. Define clear handler contract
2. Document chain behavior
3. Handle unprocessed requests
4. Avoid infinite loops in chain
5. Keep handlers focused
6. Consider handler ordering
7. Log at each stage
8. Provide default handler

7.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java

8 Command Pattern

8.1 📋 Overview

The Command pattern encapsulates a request as an object, allowing parameterization of clients with different requests, queuing of requests, and logging of requests.

8.2 🎯 Intent

Problem Solved: - Encapsulate a request as an object - Decouple the object that invokes an operation from the one that performs it - Allow undo/redo functionality - Queue commands for deferred execution

8.3 👥 Roles & Responsibilities

8.4 💡 Code Example

public interface Command {
    void execute();
    void undo();
}

public class LightOnCommand implements Command {
    private Light light;
    
    public LightOnCommand(Light light) {
        this.light = light;
    }
    
    @Override
    public void execute() {
        light.on();
    }
    
    @Override
    public void undo() {
        light.off();
    }
}

// Invoker
public class RemoteControl {
    private List<Command> commands = new ArrayList<>();
    
    public void pressButton(Command command) {
        command.execute();
        commands.add(command);
    }
    
    public void undo() {
        if (!commands.isEmpty()) {
            commands.remove(commands.size() - 1).undo();
        }
    }
}

// Usage
RemoteControl remote = new RemoteControl();
remote.pressButton(new LightOnCommand(light));
remote.undo();

Reasoning: Requests encapsulated as objects enabling queuing, undoing, and macro commands.

8.5 📊 Class Diagram

classDiagram
    class Client
    class Invoker {
        -command: Command
        +setCommand(c: Command)
        +invoke()
    }
    class Command {
        <<interface>>
        +execute()
    }
    class ConcreteCommand
    class Receiver {
        +action()
    }
    Client --> Invoker
    Invoker --> Command
    Command <|-- ConcreteCommand
    ConcreteCommand --> Receiver

8.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Invoker: setCommand(cmd)
    Client->>Invoker: invoke()
    Invoker->>Command: execute()
    Command->>Receiver: action()

8.7 ⚖️ Trade-offs

8.7.1 Advantages ✅

• Decouples invoker from receiver
• Easy to add new commands
• Supports undo/redo
• Can queue commands
• Supports command macros
• Deferred execution

8.7.2 Disadvantages ❌

• More classes required
• Increased memory usage
• Complexity for simple operations
• Undo/redo state management
• Performance overhead

8.8 🌍 Real-World Use Cases

• GUI button actions
• Undo/redo functionality
• Task queuing systems
• Macro recording
• Transaction systems
• Remote procedure calls

8.9 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)

9 Composite Pattern

9.1 📋 Overview

This folder contains the Composite design pattern implementation.

9.2 🎯 Intent

The composite pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

9.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

9.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

9.5 📊 Class Diagram

classDiagram
    class Client
    class Component {
        <<interface>>
        +operation()
    }
    class Leaf
    class Composite {
        -children: List<Component>
        +add(c: Component)
        +operation()
    }
    Client --> Component
    Component <|-- Leaf
    Component <|-- Composite
    Composite --> Component

9.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Composite: operation()
    loop children
        Composite->>Component: operation()
    end
    Composite-->>Client: result

9.7 ⚖️ Trade-offs

9.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

9.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

9.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

9.9 ⚠️ Common Anti-Patterns

9.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

9.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

9.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

9.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

10 Decorator Pattern

10.1 📋 Overview

This folder contains the Decorator design pattern implementation.

10.2 🎯 Intent

The decorator pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

10.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

10.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

10.5 📊 Class Diagram

classDiagram
    class Client
    class Component {
        <<interface>>
        +operation()
    }
    class ConcreteComponent
    class Decorator {
        -component: Component
        +operation()
    }
    class ConcreteDecorator
    Client --> Component
    Component <|-- ConcreteComponent
    Component <|-- Decorator
    Decorator <|-- ConcreteDecorator
    Decorator --> Component

10.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Decorator: operation()
    Decorator->>Component: operation()
    Component-->>Decorator: result
    Decorator-->>Client: result

10.7 ⚖️ Trade-offs

10.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

10.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

10.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

10.9 ⚠️ Common Anti-Patterns

10.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

10.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

10.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

10.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

11 Double-Checked Locking Pattern

11.1 📋 Overview

The Double-Checked Locking pattern is a thread-safe lazy initialization technique that minimizes synchronization overhead.

11.2 🎯 Intent

Problem Solved: - Thread-safe lazy initialization - Minimize synchronization overhead - Defer object creation until needed - Efficient repeated access

11.3 💡 Implementation

public class DoubleCheckedLocking {
    private volatile static Instance instance;
    
    public static Instance getInstance() {
        if (instance == null) {
            synchronized(DoubleCheckedLocking.class) {
                if (instance == null) {
                    instance = new Instance();
                }
            }
        }
        return instance;
    }
}

11.4 ⚠️ Considerations

• Requires volatile keyword
• Subtle synchronization issues
• Java Memory Model dependent
• Bill Pugh Singleton often better
• Enum Singleton recommended

11.5 📊 Class Diagram

classDiagram
    class Client
    class Singleton {
        -static instance: Singleton
        +getInstance(): Singleton
    }
    Client --> Singleton

11.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Singleton: getInstance()
    alt instance == null
        Client->>Singleton: synchronize
        Singleton->>Singleton: create instance
    end
    Singleton-->>Client: instance

11.7 📚 References

• Double-Checked Locking pattern
• Effective Java Chapter on Lazy Initialization

12 Facade Pattern

12.1 📋 Overview

This folder contains the Facade design pattern implementation.

12.2 🎯 Intent

The facade pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

12.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

12.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

12.5 📊 Class Diagram

classDiagram
    class Client
    class Facade {
        +operation()
    }
    class SubsystemA
    class SubsystemB
    class SubsystemC
    Client --> Facade
    Facade --> SubsystemA
    Facade --> SubsystemB
    Facade --> SubsystemC

12.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Facade: operation()
    Facade->>SubsystemA: doA()
    Facade->>SubsystemB: doB()
    Facade->>SubsystemC: doC()
    Facade-->>Client: result

12.7 ⚖️ Trade-offs

12.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

12.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

12.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

12.9 ⚠️ Common Anti-Patterns

12.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

12.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

12.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

12.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

13 Factory Method Pattern

13.1 📋 Overview

The Factory Method Pattern defines an interface for creating an object, letting subclasses decide which class to instantiate.

13.2 🎯 Intent

Problem Solved: - You need to create objects but don’t know the concrete class until runtime - You want subclasses to specify the objects they create - Object creation logic should be separate from usage

Use When: - A class cannot anticipate the type of objects it needs to create - You want subclasses to specify the objects they create - Object creation logic should be separate from business logic

13.3 👥 Roles & Responsibilities

13.4 💡 Code Example

// Product Interface
public interface Transport {
    void deliver(String cargo);
}

// Concrete Products
public class Truck implements Transport {
    @Override
    public void deliver(String cargo) {
        System.out.println("Truck delivering: " + cargo);
    }
}

// Creator (Abstract)
public abstract class Logistics {
    abstract Transport createTransport();
    
    public void planDelivery(String cargo) {
        Transport transport = createTransport();
        transport.deliver(cargo);
    }
}

// Concrete Creator
public class RoadLogistics extends Logistics {
    @Override
    Transport createTransport() {
        return new Truck();
    }
}

// Usage
Logistics logistics = new RoadLogistics();
logistics.planDelivery("Package");

Reasoning: Clients depend on abstractions, not concrete classes. Subclasses decide what product to create. Promotes loose coupling and flexibility.

13.5 🔀 Design Principles

• Dependency Inversion Principle: Depend on abstractions
• Open/Closed Principle: New products without modifying Creator
• Single Responsibility Principle: Creator handles only creation logic

13.6 📊 Class Diagram

classDiagram
    class Client
    class Creator {
        <<abstract>>
        +factoryMethod(): Product
        +anOperation()
    }
    class ConcreteCreator
    class Product {
        <<interface>>
        +use()
    }
    class ConcreteProduct
    Client --> Creator
    Creator <|-- ConcreteCreator
    Product <|-- ConcreteProduct
    Creator --> Product

13.7 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Creator: anOperation()
    Creator->>Creator: factoryMethod()
    Creator->>Product: use()
    Product-->>Creator: result
    Creator-->>Client: result

13.8 ⚖️ Trade-offs

13.8.1 Advantages ✅

• Decouples creator from concrete products
• Encapsulates creation logic
• Easier to add new product types
• Cleaner code than multiple if-else branches

13.8.2 Disadvantages ❌

• Creates subclass hierarchy just for creation
• Can be overkill for simple scenarios
• More complex than direct instantiation
• Multiple files for simple variations

13.9 🚫 When NOT to Use

• Simple objects with straightforward creation - Use direct instantiation
• Single product type - Unnecessary abstraction
• Static factory methods sufficient - Use static factories instead

13.10 ⚠️ Common Anti-Patterns

13.11 🌍 Real-World Use Cases

• Java Collections: List.of(), Set.of()
• SLF4J: LoggerFactory.getLogger()
• JDBC: DriverManager.getConnection()
• XML: DocumentBuilderFactory.newInstance()

13.12 🔗 Alternatives & Similar Patterns

13.13 📝 Best Practices

1. Keep factory interface simple and intuitive
2. Avoid making factory methods do too much
3. Document expected exceptions
4. Provide clear naming for factory methods
5. Consider static factory methods for simplicity
6. Ensure thread-safety if needed
7. Validate inputs before creating objects
8. Provide sensible defaults where possible

13.14 🎓 Related Patterns

• Abstract Factory
• Builder Pattern
• Prototype Pattern
• Singleton Pattern

13.15 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java (Edith Freeman et al.)

14 Filter Pattern

14.1 📋 Overview

The Filter pattern (or Criteria pattern) provides a way to filter collections of objects using different criteria in a flexible and reusable manner.

14.2 🎯 Intent

Problem Solved: - Filter collections by different criteria - Combine multiple filter criteria - Avoid multiple if-else statements - Enable reusable filter components

14.3 👥 Roles & Responsibilities

14.4 💡 Implementation

• Each filter criterion is a separate component
• Filters can be combined/chained
• Enables dynamic filtering logic
• Reusable and testable filters

14.5 📊 Class Diagram

classDiagram
    class Client
    class Criteria {
        <<interface>>
        +meetCriteria(items)
    }
    class ConcreteCriteriaA
    class ConcreteCriteriaB
    class AndCriteria
    class OrCriteria
    Client --> Criteria
    Criteria <|-- ConcreteCriteriaA
    Criteria <|-- ConcreteCriteriaB
    Criteria <|-- AndCriteria
    Criteria <|-- OrCriteria
    AndCriteria --> Criteria
    OrCriteria --> Criteria

14.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Criteria: meetCriteria(items)
    Criteria-->>Client: filteredItems

14.7 ⚖️ Trade-offs

14.7.1 Advantages ✅

• Flexible filtering logic
• Reusable criteria
• Easy combination of filters
• Clear separation of concerns
• Testable filter logic

14.7.2 Disadvantages ❌

• Additional classes required
• Performance with many filters
• Memory overhead for criteria objects
• Learning curve
• Over-engineering for simple cases

14.8 🌍 Real-World Use Cases

• Database query builders
• Collection filtering
• Stream filtering
• Search functionality
• Data validation chains

14.9 📚 References

• Criteria Pattern
• Chain of Responsibility Pattern

15 Flyweight Pattern

15.1 📋 Overview

This folder contains the Flyweight design pattern implementation.

15.2 🎯 Intent

The flyweight pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

15.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

15.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

15.5 📊 Class Diagram

classDiagram
    class Client
    class Flyweight {
        <<interface>>
        +operation(extrinsic)
    }
    class ConcreteFlyweight
    class FlyweightFactory {
        -pool: Map
        +getFlyweight(key)
    }
    Client --> FlyweightFactory
    Flyweight <|-- ConcreteFlyweight
    FlyweightFactory --> Flyweight

15.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>FlyweightFactory: getFlyweight(key)
    FlyweightFactory-->>Client: Flyweight
    Client->>Flyweight: operation(extrinsicState)

15.7 ⚖️ Trade-offs

15.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

15.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

15.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

15.9 ⚠️ Common Anti-Patterns

15.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

15.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

15.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

15.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

16 Interpreter Pattern

16.1 📋 Overview

The Interpreter pattern defines a grammatical representation for a language and an interpreter to interpret sentences in that language.

16.2 🎯 Intent

Problem Solved: - Define grammar for domain-specific language - Parse and execute expressions - Build abstract syntax trees - Evaluate language sentences

16.3 👥 Roles & Responsibilities

16.4 💡 Implementation

• Grammar defined by class hierarchy
• Each expression type is a class
• interpret() evaluates expression
• Recursive interpretation of tree

16.5 📊 Class Diagram

classDiagram
    class Client
    class Context
    class AbstractExpression {
        <<interface>>
        +interpret(ctx: Context)
    }
    class TerminalExpression
    class NonterminalExpression {
        -left: AbstractExpression
        -right: AbstractExpression
    }
    Client --> AbstractExpression
    AbstractExpression <|-- TerminalExpression
    AbstractExpression <|-- NonterminalExpression
    AbstractExpression --> Context
    NonterminalExpression --> AbstractExpression

16.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>AbstractExpression: interpret(context)
    AbstractExpression->>AbstractExpression: interpret(child)
    AbstractExpression-->>Client: result

16.7 ⚖️ Trade-offs

16.7.1 Advantages ✅

• Easy to modify grammar
• Grammar in code form
• Extensible expressions
• Recursive evaluation
• Natural language representation

16.7.2 Disadvantages ❌

• Complex for large grammars
• Performance overhead
• Many classes required
• Difficult to parse
• Memory consumption

16.8 🌍 Real-World Use Cases

• Expression evaluators
• DSL (Domain-Specific Language) implementation
• SQL query processing
• Regular expression engines
• Configuration file parsing

16.9 📚 References

• Gang of Four Design Patterns
• Language design patterns

17 Iterator Pattern

17.1 📋 Overview

The Iterator pattern provides a way to access elements of a collection sequentially without exposing its underlying representation.

17.2 🎯 Intent

Problem Solved: - Access collection elements without exposing structure - Support multiple simultaneous traversals - Provide uniform interface for different collections - Hide collection implementation details

17.3 👥 Roles & Responsibilities

17.4 💡 Implementation

Java’s Iterator interface: - hasNext(): Check if more elements - next(): Get next element - remove(): Remove current element

17.5 📊 Class Diagram

classDiagram
    class Client
    class Iterator {
        <<interface>>
        +hasNext()
        +next()
    }
    class ConcreteIterator
    class Aggregate {
        <<interface>>
        +createIterator(): Iterator
    }
    class ConcreteAggregate
    Client --> Aggregate
    Aggregate <|-- ConcreteAggregate
    Iterator <|-- ConcreteIterator
    ConcreteAggregate --> ConcreteIterator

17.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Aggregate: createIterator()
    Aggregate-->>Client: Iterator
    loop until done
        Client->>Iterator: hasNext()
        Client->>Iterator: next()
    end

17.7 ⚖️ Trade-offs

17.7.1 Advantages ✅

• Uniform traversal interface
• Hides collection structure
• Supports multiple iterations
• Decouples collection from traversal
• Different iteration strategies

17.7.2 Disadvantages ❌

• Additional complexity
• Iterator overhead
• State management in iterator
• Concurrent modification issues
• Performance impact

17.8 🌍 Real-World Use Cases

• Java Collections Framework
• Database result set traversal
• File system traversal
• Tree/graph traversal
• Stream processing

17.9 📚 References

• Gang of Four Design Patterns
• Java Collections Framework
• Iterator design

18 Lazy Sequence Pattern

18.1 📋 Overview

The Lazy Sequence pattern defers sequence element computation until they’re actually accessed, enabling efficient processing of potentially infinite sequences.

18.2 🎯 Intent

Problem Solved: - Defer expensive computations - Handle potentially infinite sequences - Support streaming data processing - Reduce memory usage

18.3 👥 Roles & Responsibilities

18.4 💡 Implementation

• Elements computed on first access
• Caching computed results
• Support for infinite sequences
• Memory-efficient processing

18.5 📊 Class Diagram

classDiagram
    class Client
    class LazySequence {
        -cache: Map
        -generator: ElementGenerator
        +get(index)
    }
    class ElementGenerator {
        <<interface>>
        +compute(index)
    }
    Client --> LazySequence
    LazySequence --> ElementGenerator

18.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>LazySequence: get(index)
    alt cached
        LazySequence-->>Client: element
    else not cached
        LazySequence->>ElementGenerator: compute(index)
        ElementGenerator-->>LazySequence: element
        LazySequence-->>Client: element
    end

18.7 ⚖️ Trade-offs

18.7.1 Advantages ✅

• Deferred expensive computations
• Memory efficient
• Support infinite sequences
• Streaming processing
• Computation on demand

18.7.2 Disadvantages ❌

• Harder to understand
• Non-deterministic timing
• Caching overhead
• Debugging complexity
• First-access latency

18.8 🌍 Real-World Use Cases

• Stream API implementations
• Iterator patterns
• Reactive programming
• Data pipeline processing
• Infinite sequence generation

18.9 📚 References

• Lazy evaluation patterns
• Functional programming concepts
• Stream processing

19 Mediator Pattern

19.1 📋 Overview

The Mediator pattern defines an object that encapsulates how a set of objects interact. It promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently.

19.2 🎯 Intent

Problem Solved: - Objects communicate in complex ways - Direct references create tight coupling - Communication logic scattered across classes - Adding new interaction types requires modifications

19.3 👥 Roles & Responsibilities

19.4 💡 Implementation

• Colleagues reference mediator
• Mediator knows all colleagues
• Communication routed through mediator
• Mediator implements distribution logic

19.5 📊 Class Diagram

classDiagram
    class Mediator {
        <<interface>>
        +notify(sender, event)
    }
    class ConcreteMediator
    class Colleague {
        -mediator: Mediator
        +send(event)
    }
    class ColleagueA
    class ColleagueB
    Mediator <|-- ConcreteMediator
    Colleague <|-- ColleagueA
    Colleague <|-- ColleagueB
    Colleague --> Mediator
    ConcreteMediator --> ColleagueA
    ConcreteMediator --> ColleagueB

19.6 🔄 Sequence Diagram

sequenceDiagram
    participant ColleagueA
    participant Mediator
    participant ColleagueB
    ColleagueA->>Mediator: notify(A, event)
    Mediator->>ColleagueB: receive(event)

19.7 ⚖️ Trade-offs

19.7.1 Advantages ✅

• Decouples colleagues
• Centralizes control
• Easy to modify interactions
• Simplifies colleague classes
• Reusable colleagues

19.7.2 Disadvantages ❌

• Mediator complexity
• God Object risk
• Performance overhead
• Debugging difficulty
• Hidden dependencies

19.8 🌍 Real-World Use Cases

• ChatRoom mediator
• Dialog box coordinators
• Air traffic control
• Central event dispatcher
• Workflow engines

19.9 📚 References

• Gang of Four Design Patterns
• Coordination patterns

20 Memento Pattern

20.1 📋 Overview

The Memento pattern captures and externalizes an object’s internal state without violating encapsulation, and allows the object to be restored to this state later.

20.2 🎯 Intent

Problem Solved: - Save and restore object state - Implement undo/redo functionality - Without exposing internal structure - Without violating encapsulation

20.3 👥 Roles & Responsibilities

20.4 💡 Implementation

• Memento stores state snapshot
• Originator creates/uses mementos
• Caretaker manages memento collection
• Enables state history management

20.5 📊 Class Diagram

classDiagram
    class Client
    class Originator {
        +createMemento(): Memento
        +restore(m: Memento)
    }
    class Memento
    class Caretaker {
        -history: List<Memento>
    }
    Client --> Originator
    Client --> Caretaker
    Originator --> Memento
    Caretaker --> Memento

20.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Originator: createMemento()
    Originator-->>Client: Memento
    Client->>Caretaker: store(memento)
    Client->>Originator: restore(memento)

20.7 ⚖️ Trade-offs

20.7.1 Advantages ✅

• Encapsulation preserved
• Simple undo/redo
• State history management
• Serialization support
• Snapshot capability

20.7.2 Disadvantages ❌

• Memory overhead
• Performance cost for large objects
• Serialization complexity
• State consistency management
• Storage requirements

20.8 🌍 Real-World Use Cases

• Text editor undo/redo
• Database transactions
• Game state saves
• Configuration snapshots
• Version control systems

20.9 📚 References

• Gang of Four Design Patterns
• State management patterns

21 Method Object Pattern

21.1 📋 Overview

The Method Object pattern converts a method into an object, enabling flexible method parameter passing and invocation.

21.2 🎯 Intent

Problem Solved: - Complex methods with many parameters - Need to pass methods as parameters - Deferred method execution - Method state management

21.3 👥 Roles & Responsibility

• Encapsulate method as object
• Enable method parameter passing
• Manage method state
• Support deferred execution

21.4 📊 Class Diagram

classDiagram
    class Client
    class MethodObject {
        <<interface>>
        +execute()
    }
    class ConcreteMethodObject
    class Host {
        +helper()
    }
    Client --> MethodObject
    MethodObject <|-- ConcreteMethodObject
    ConcreteMethodObject --> Host

21.5 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>MethodObject: execute()
    MethodObject->>Host: helper()

21.6 🌍 Real-World Use Cases

• Callback mechanisms
• Command pattern implementation
• Functional programming patterns
• Task queuing systems
• Async operation handlers

21.7 📚 References

• Gang of Four Design Patterns
• Functional programming patterns

22 Model-View-Presenter Pattern

22.1 📋 Overview

The Model-View-Presenter (MVP) pattern separates presentation logic from business logic by introducing a presenter component that mediates between the view and model.

22.2 🎯 Intent

Problem Solved: - Separate UI from business logic - Make UI components testable - Enable code reuse across UI frameworks - Improve maintainability of UI code

22.3 👥 Roles & Responsibilities

22.4 💡 Implementation

• View is passive (no business logic)
• Presenter handles all UI logic
• Model remains UI-independent
• MVP enables testing without UI framework

22.5 📊 Class Diagram

classDiagram
    class Model
    class View {
        <<interface>>
        +render(data)
    }
    class Presenter {
        -model: Model
        -view: View
        +onViewEvent()
    }
    class ConcreteView
    View <|-- ConcreteView
    Presenter --> Model
    Presenter --> View
    ConcreteView --> Presenter

22.6 🔄 Sequence Diagram

sequenceDiagram
    actor User
    participant View
    participant Presenter
    participant Model
    User->>View: interact()
    View->>Presenter: event()
    Presenter->>Model: update()
    Model-->>Presenter: data
    Presenter->>View: render(data)

22.7 ⚖️ Trade-offs

22.7.1 Advantages ✅

• Clear separation of concerns
• Testable UI logic
• Reusable presenters
• Framework independence
• Flexible UI

22.7.2 Disadvantages ❌

• More classes and complexity
• Boilerplate code
• Learning curve
• Performance overhead
• Over-engineering for simple UIs

22.8 🌍 Real-World Use Cases

• Android applications
• Desktop GUI applications
• Web application presenters
• Testing UI behavior
• Multi-platform applications

22.9 📚 References

• MVP architecture
• Martin Fowler MVP article
• Android MVP pattern

23 Null Object Pattern

23.1 📋 Overview

The Null Object pattern provides an object as a surrogate for null references, avoiding null checks throughout the code.

23.2 🎯 Intent

Problem Solved: - Eliminate null reference checks - Provide default behavior for null case - Improve code clarity - Reduce NullPointerException risks

23.3 💡 Implementation

Instead of:

if (logger != null) {
    logger.log("message");
}

Use:

logger.log("message");  // Works with NullLogger

23.4 📊 Class Diagram

classDiagram
    class Client
    class AbstractObject {
        <<interface>>
        +operation()
    }
    class RealObject
    class NullObject
    Client --> AbstractObject
    AbstractObject <|-- RealObject
    AbstractObject <|-- NullObject

23.5 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>AbstractObject: operation()
    AbstractObject-->>Client: result

23.6 ⚖️ Trade-offs

23.6.1 Advantages ✅

• Eliminates null checks
• Default behavior encapsulated
• Cleaner code
• Safer code
• Visitor pattern support

23.6.2 Disadvantages ❌

• Silent failures possible
• Harder to detect issues
• Performance overhead
• Over-abstraction risk
• Debugging complexity

23.7 🌍 Real-World Use Cases

• Logging no-op implementations
• Optional services
• Collection empty implementations
• Null object patterns in frameworks

23.8 📚 References

• Null Object pattern
• Optional design

24 Observer Pattern

24.1 📋 Overview

The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.

24.2 🎯 Intent

Problem Solved: - An object’s state changes and other objects need to be notified - Notify multiple objects without tight coupling - Enable event-driven architecture

24.3 👥 Roles & Responsibilities

24.4 💡 Code Example

public interface Observer {
    void update(String message);
}

public class Subject {
    private List<Observer> observers = new ArrayList<>();
    
    public void attach(Observer observer) {
        observers.add(observer);
    }
    
    public void detach(Observer observer) {
        observers.remove(observer);
    }
    
    public void notifyObservers(String message) {
        for (Observer observer : observers) {
            observer.update(message);
        }
    }
}

public class ConcreteObserver implements Observer {
    private String name;
    
    @Override
    public void update(String message) {
        System.out.println(name + " received: " + message);
    }
}

// Usage
Subject subject = new Subject();
Observer obs1 = new ConcreteObserver();
subject.attach(obs1);
subject.notifyObservers("Event occurred");

Reasoning: Loose coupling between Subject and Observers; enables dynamic subscription model.

24.5 📊 Class Diagram

classDiagram
    class Subject {
        +attach(o: Observer)
        +detach(o: Observer)
        +notify()
    }
    class ConcreteSubject
    class Observer {
        <<interface>>
        +update()
    }
    class ConcreteObserver
    Subject <|-- ConcreteSubject
    Observer <|-- ConcreteObserver
    Subject --> Observer

24.6 🔄 Sequence Diagram

sequenceDiagram
    participant Observer
    participant Subject
    Observer->>Subject: attach()
    Subject->>Subject: changeState()
    Subject->>Observer: notify()
    Observer->>Observer: update()

24.7 ⚖️ Trade-offs

24.7.1 Advantages ✅

• Loose coupling
• Dynamic observer management
• Supports broadcast communications
• Natural event handling
• Promotes reactive programming

24.7.2 Disadvantages ❌

• Observer ordering unpredictable
• Memory overhead (observer references)
• Performance impact with many observers
• Difficult to trace event flow
• Can lead to memory leaks

24.8 🌍 Real-World Use Cases

• Event listeners in GUI frameworks
• Message passing systems
• Reactive programming libraries
• Model-View patterns
• Pub/Sub systems

24.9 📚 References

• Gang of Four Design Patterns
• Reactive Programming concepts
• Event-driven architecture

25 Pipes and Filters Pattern

25.1 📋 Overview

The Pipes and Filters pattern processes data through a series of independent, modular processing components (filters) connected by data flow channels (pipes).

25.2 🎯 Intent

Problem Solved: - Process complex workflows through independent stages - Enable modular, reusable components - Support different processing orders - Parallel and sequential processing

25.3 👥 Roles & Responsibilities

25.4 📊 Class Diagram

classDiagram
    class Source
    class Pipe
    class Filter {
        +process(data)
    }
    class Sink
    Source --> Pipe
    Pipe --> Filter
    Filter --> Pipe
    Pipe --> Sink

25.5 🔄 Sequence Diagram

sequenceDiagram
    participant Source
    participant Pipe1
    participant Filter
    participant Pipe2
    participant Sink
    Source->>Pipe1: emit(data)
    Pipe1->>Filter: data
    Filter->>Pipe2: processed
    Pipe2->>Sink: processed

25.6 ⚖️ Trade-offs

25.6.1 Advantages ✅

• Modularity and reusability
• Flexible data processing
• Parallel processing support
• Easy to reconfigure
• Independent testing

25.6.2 Disadvantages ❌

• Complexity with many filters
• Data transformation overhead
• Error handling complexity
• Debugging difficulty
• Performance considerations

25.7 🌍 Real-World Use Cases

• Unix pipelines
• Data ETL processes
• Image processing pipelines
• Stream processing frameworks
• Log processing

25.8 📚 References

• Enterprise Integration Patterns
• Data pipeline architecture

26 Prototype Pattern

26.1 📋 Overview

This folder contains the Prototype design pattern implementation.

26.2 🎯 Intent

The prototype pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

26.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

26.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

26.5 📊 Class Diagram

classDiagram
    class Client
    class Prototype {
        <<interface>>
        +clone()
    }
    class ConcretePrototype
    Client --> Prototype
    Prototype <|-- ConcretePrototype

26.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Prototype: clone()
    Prototype-->>Client: copy

26.7 ⚖️ Trade-offs

26.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

26.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

26.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

26.9 ⚠️ Common Anti-Patterns

26.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

26.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

26.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

26.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

27 Proxy Pattern

27.1 📋 Overview

This folder contains the Proxy design pattern implementation.

27.2 🎯 Intent

The proxy pattern solves a specific structural or behavioral problem in software design by providing reusable solutions.

27.3 👥 Roles & Responsibilities

This pattern involves multiple roles working together to achieve separation of concerns and flexibility.

27.4 💡 Code Example

Please see the src/ directory for complete, executable code examples demonstrating this pattern.

27.5 📊 Class Diagram

classDiagram
    class Client
    class Subject {
        <<interface>>
        +request()
    }
    class RealSubject
    class Proxy {
        -real: RealSubject
        +request()
    }
    Client --> Subject
    Subject <|-- RealSubject
    Subject <|-- Proxy
    Proxy --> RealSubject

27.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Proxy: request()
    Proxy->>RealSubject: request()
    RealSubject-->>Proxy: result
    Proxy-->>Client: result

27.7 ⚖️ Trade-offs

27.7.1 Advantages ✅

• Provides structured solution
• Promotes code reusability
• Improves maintainability

27.7.2 Disadvantages ❌

• May add complexity
• Performance overhead
• Learning curve

27.8 🚫 When NOT to Use

• For simple scenarios where direct solutions suffice
• When performance is critical and overhead is unacceptable
• In situations where the pattern doesn’t naturally fit

27.9 ⚠️ Common Anti-Patterns

27.10 🌍 Real-World Use Cases

This pattern appears frequently in: - Enterprise applications - Framework and library design - System integration scenarios

27.11 🔗 Alternatives & Similar Patterns

• Other structural/behavioral patterns
• Simpler direct approaches
• Complementary patterns

27.12 📝 Best Practices

1. Understand the problem before applying the pattern
2. Document your pattern usage clearly
3. Keep implementations simple
4. Test thoroughly
5. Consider performance implications
6. Review periodically for improvements
7. Teach team members about the pattern
8. Refactor if pattern no longer applies

27.13 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Design Patterns in Java
• Refactoring Guru

For detailed implementation, see the source files in src/.

28 Servant Pattern

28.1 📋 Overview

The Servant pattern defines common functionality in a separate class (servant) that serves multiple classes, enabling code reuse without inheritance.

28.2 🎯 Intent

Problem Solved: - Provide common functionality to multiple unrelated classes - Avoid code duplication without inheritance - Reduce class hierarchy complexity - Enable flexible behavior sharing

28.3 👥 Roles & Responsibilities

28.4 💡 Implementation

• Servant contains common operations
• Served classes delegate to servant
• Enables composition over inheritance
• No inheritance relationship required

28.5 📊 Class Diagram

classDiagram
    class Client
    class Servant {
        +operation(served)
    }
    class ServedA
    class ServedB
    Client --> Servant
    Servant --> ServedA
    Servant --> ServedB

28.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Servant: operation(served)
    Servant->>ServedA: doWork()
    Servant-->>Client: result

28.7 ⚖️ Trade-offs

28.7.1 Advantages ✅

• Code reuse without inheritance
• Flexible behavior sharing
• Avoids multiple inheritance
• Clean separation of concerns
• Reusable servant components

28.7.2 Disadvantages ❌

• Additional object dependencies
• Parameter passing complexity
• Servant state management
• Performance overhead
• Design complexity

28.8 🌍 Real-World Use Cases

• Utility classes
• Shared behavior across unrelated classes
• Cross-cutting concerns
• Aspect-oriented design
• Mixin functionality

28.9 📚 References

• Servant Pattern
• Design Patterns in Practice

29 Service Locator Pattern

29.1 📋 Overview

The Service Locator pattern centralizes logic for creating and accessing services, providing a single point for service instantiation and discovery.

29.2 🎯 Intent

Problem Solved: - Decouple service creation from usage - Provide single service access point - Enable service substitution - Centralize service configuration

29.3 👥 Roles & Responsibilities

29.4 ⚠️ Note

Service Locator is often considered an anti-pattern. Dependency Injection is the preferred modern approach.

29.5 📊 Class Diagram

classDiagram
    class Client
    class ServiceLocator {
        +getService(name)
    }
    class Service {
        <<interface>>
        +execute()
    }
    class ConcreteServiceA
    class ConcreteServiceB
    Client --> ServiceLocator
    Service <|-- ConcreteServiceA
    Service <|-- ConcreteServiceB
    ServiceLocator --> Service

29.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>ServiceLocator: getService(name)
    ServiceLocator-->>Client: Service
    Client->>Service: execute()

29.7 ⚖️ Trade-offs

29.7.1 Advantages ✅

• Centralized service management
• Easy service substitution
• Decouples client from creation
• Dynamic service loading

29.7.2 Disadvantages ❌

• Hidden dependencies
• Testing complexity
• Global state issues
• Service locator coupling
• Anti-pattern warning

29.8 🌍 Real-World Use Cases

• Legacy application service management
• Plugin systems
• Dynamic service discovery
• Configuration-driven services

29.9 📚 References

• Martin Fowler Service Locator
• Dependency Injection advantages

30 Singleton Pattern

30.1 📋 Overview

The Singleton Pattern ensures that a class has only one instance and provides a global point of access to it. This is a creational pattern that restricts object instantiation to a single instance while providing a mechanism to access that instance universally.

30.2 🎯 Intent

Problem Solved: - You need to guarantee that only one instance of a class exists throughout the application lifecycle - Multiple instances would cause logical errors or resource conflicts (e.g., database connections, configuration managers, logging services) - You need a globally accessible point of access to this single instance without passing references through all layers

Use When: - You need a single, shared resource manager (connection pools, thread pools, caches) - You need a centralized configuration holder or registry - You need exactly one instance of a service to coordinate system-wide activities

30.3 👥 Roles & Responsibilities

Key Characteristics: - Private constructor prevents external instantiation - Static instance variable holds the single object - Public static accessor method (getInstance()) returns the instance - Thread-safety considerations for multi-threaded environments

30.4 💡 Implementation Strategies

This pattern has multiple implementations, each with different trade-offs:

30.4.1 1. Eager Initialization

public class EagerInitializedSingleton {
    private static final EagerInitializedSingleton instance = 
        new EagerInitializedSingleton();
    
    private EagerInitializedSingleton() { }
    
    public static EagerInitializedSingleton getInstance() {
        return instance;
    }
}

Reasoning: Instance created when class is loaded. Thread-safe by default but allocates memory immediately.

30.4.2 2. Lazy Initialization with Synchronization

public class ThreadSafeSingleton {
    private static ThreadSafeSingleton instance;
    
    private ThreadSafeSingleton() { }
    
    public static synchronized ThreadSafeSingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeSingleton();
        }
        return instance;
    }
}

Reasoning: Creates instance on first use. Synchronized method ensures thread-safety but causes synchronization overhead on every call.

30.4.3 3. Double-Checked Locking

public class ThreadSafeSingleton {
    private static ThreadSafeSingleton instance;
    
    private ThreadSafeSingleton() { }
    
    public static ThreadSafeSingleton getInstance() {
        if (instance == null) {
            synchronized (ThreadSafeSingleton.class) {
                if (instance == null) {
                    instance = new ThreadSafeSingleton();
                }
            }
        }
        return instance;
    }
}

Reasoning: Checks instance twice—once outside lock, once inside. Reduces synchronization overhead while ensuring thread-safety.

30.4.4 4. Bill Pugh Singleton (Class Loader)

public class BillPughSingleton {
    private BillPughSingleton() { }
    
    private static class SingletonHelper {
        private static final BillPughSingleton instance = 
            new BillPughSingleton();
    }
    
    public static BillPughSingleton getInstance() {
        return SingletonHelper.instance;
    }
}

Reasoning: Uses inner class to achieve lazy initialization. Thread-safe by design and efficient (no synchronization overhead).

30.5 📊 Class Diagram

classDiagram
    class Client
    class Singleton {
        -static instance: Singleton
        +getInstance(): Singleton
    }
    Client --> Singleton

30.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Singleton: getInstance()
    Singleton-->>Client: instance

30.7 🔀 Design Principles Emphasized

30.8 ⚖️ Trade-offs

30.8.1 Advantages ✅

• Global Access: Provides easy, centralized access to shared resource
• Controlled Instantiation: Guarantees exactly one instance exists
• Lazy Initialization (Option Dependent): Defers object creation until needed
• Memory Efficient: Only one instance in memory
• Thread-Safe (Option Dependent): Several implementations are inherently thread-safe

30.8.2 Disadvantages ❌

• Testing Difficulty: Hard to mock for unit tests; global state complicates testing
• Hidden Dependencies: Not obvious that code depends on a singleton; dependencies are implicit
• Synchronization Overhead: Lock-based implementations add performance cost
• Violates Single Responsibility: Often handles both instantiation and business logic
• Rigid: Extending or replacing the singleton is difficult without modifying client code
• Global State: Makes code less predictable and harder to reason about
• Concurrency Issues: Some implementations (eager loading) may fail under specific multi-threaded scenarios

30.9 🚫 When NOT to Use

30.10 ⚠️ Common Anti-Patterns & Misuses

30.11 🌍 Real-World Use Cases

30.11.1 Spring Framework

// Spring beans are singletons by default
@Service
public class UserService {
    // Only one instance in Spring Container
}

// Access via Dependency Injection
@Component
public class UserController {
    @Autowired
    private UserService userService;  // Singleton instance injected
}

30.11.2 Log4j / SLF4J

// Logger is typically a singleton
Logger logger = LoggerFactory.getLogger(MyClass.class);
// Returns same logger instance for same class name

30.11.3 Database Connection Pool

// ConnectionPool as singleton to manage all connections
public class ConnectionPool {
    private static final ConnectionPool instance = new ConnectionPool();
    
    public static ConnectionPool getInstance() {
        return instance;
    }
}

30.11.4 Configuration Manager

// Singleton holding application configuration
public class AppConfig {
    private static final AppConfig instance = new AppConfig();
    
    public String getDatabaseUrl() { /* ... */ }
    public int getMaxConnections() { /* ... */ }
}

30.12 🔗 Alternatives & Similar Patterns

30.13 📝 Best Practices

1. Prefer Dependency Injection: Use DI container (Spring, Guice) instead of manual singleton management
2. Make Thread-Safe: Use Bill Pugh Singleton or eager initialization for multi-threaded applications
3. Document Constraints: Clearly state that your class is a singleton and why
4. Provide Test Hooks: Add methods to reset state for testing
5. Avoid Mutable State: Keep singleton data immutable or use thread-safe collections
6. Consider Enum Singleton: In Java, enum provides the most robust singleton implementation
7. Avoid as Service Locator: Don’t use singleton to hide dependencies; use dependency injection

30.14 🎓 Related Patterns

• Factory Pattern: Often works with Singleton to control creation
• Lazy Initialization: Deferring object creation until first use
• Builder Pattern: Can be used to construct complex singleton objects
• Object Pool Pattern: Similar in controlling limited resources

30.15 📚 References

• Gang of Four Design Patterns
• Effective Java (Joshua Bloch)
• Spring Framework Singleton Scope
• Enum as Singleton in Java

31 State Machine Pattern

31.1 📋 Overview

The State Machine pattern models complex workflows and state transitions using explicit state objects and transitions.

31.2 🎯 Intent

Problem Solved: - Model complex workflows with multiple states - Manage state transitions - Enforce valid state transitions - Handle state-dependent behavior

31.3 👥 Roles & Responsibilities

31.4 💡 Implementation

• States define valid transitions
• Transitions are explicit
• State machine validates transitions
• Prevents invalid state combinations

31.5 📊 Class Diagram

classDiagram
    class StateMachine {
        -current: State
        +handle(event)
    }
    class State {
        <<interface>>
        +onEvent(event)
    }
    class ConcreteStateA
    class ConcreteStateB
    class Event
    StateMachine --> State
    State <|-- ConcreteStateA
    State <|-- ConcreteStateB
    StateMachine --> Event

31.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>StateMachine: handle(event)
    StateMachine->>State: onEvent(event)
    State-->>StateMachine: nextState
    StateMachine-->>Client: transitioned

31.7 ⚖️ Trade-offs

31.7.1 Advantages ✅

• Clear state modeling
• Enforced valid transitions
• Easy to visualize workflow
• Prevents illegal states
• Maintainable complex workflows

31.7.2 Disadvantages ❌

• Increased complexity
• Many state classes
• Overhead for simple cases
• State explosion risk
• Difficult to modify existing states

31.8 🌍 Real-World Use Cases

• Workflow engines
• Protocol implementations
• Game state management
• Order processing
• TCP connection states

31.9 📚 References

• State Machine design
• Workflow patterns

32 State Pattern

32.1 📋 Overview

The State pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

32.2 🎯 Intent

Problem Solved: - Object behavior varies based on state - Large conditional statements checking state - State transitions need management

32.3 👥 Roles & Responsibilities

32.4 💡 Code Example

public interface State {
    void handle(Context context);
}

public class Context {
    private State state;
    
    public Context(State state) {
        this.state = state;
    }
    
    public void setState(State state) {
        this.state = state;
    }
    
    public void request() {
        state.handle(this);
    }
}

public class ConcreteStateA implements State {
    @Override
    public void handle(Context context) {
        System.out.println("State A handling");
        context.setState(new ConcreteStateB());
    }
}

// Usage
Context context = new Context(new ConcreteStateA());
context.request();
context.request();

Reasoning: Encapsulates state-dependent behavior; enables state-specific transitions.

32.5 📊 Class Diagram

classDiagram
    class Context {
        -state: State
        +request()
        +setState(s: State)
    }
    class State {
        <<interface>>
        +handle(ctx: Context)
    }
    class ConcreteStateA
    class ConcreteStateB
    Context --> State
    State <|-- ConcreteStateA
    State <|-- ConcreteStateB

32.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Context: request()
    Context->>State: handle(context)
    State-->>Context: maybe change state

32.7 ⚖️ Trade-offs

32.7.1 Advantages ✅

• Eliminates large conditional statements
• Localizes state-specific behavior
• Easy to add new states
• State transitions explicit
• Supports complex state machines

32.7.2 Disadvantages ❌

• Increased number of classes
• More complex than simple conditionals
• State dependency coupling
• Increased memory usage
• Performance overhead

32.8 🌍 Real-World Use Cases

• Workflow engines
• State machines
• Game object states
• TCP connection states
• Order processing workflows

32.9 📚 References

• Gang of Four Design Patterns
• State Machine Design

33 Strategy Pattern

33.1 📋 Overview

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

33.2 🎯 Intent

Problem Solved: - Multiple algorithms for a task - Algorithm selection varies - Avoid large conditional statements

33.3 👥 Roles & Responsibilities

33.4 💡 Code Example

public interface SortStrategy {
    void sort(int[] array);
}

public class Context {
    private SortStrategy strategy;
    
    public void setStrategy(SortStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void executeSort(int[] array) {
        strategy.sort(array);
    }
}

public class QuickSort implements SortStrategy {
    @Override
    public void sort(int[] array) {
        // QuickSort implementation
    }
}

// Usage
Context context = new Context();
context.setStrategy(new QuickSort());
context.executeSort(array);

Reasoning: Encapsulates algorithms; enables runtime selection; promotes composition.

33.5 📊 Class Diagram

classDiagram
    class Context {
        -strategy: Strategy
        +setStrategy(s: Strategy)
        +execute()
    }
    class Strategy {
        <<interface>>
        +algorithm()
    }
    class ConcreteStrategyA
    class ConcreteStrategyB
    Context --> Strategy
    Strategy <|-- ConcreteStrategyA
    Strategy <|-- ConcreteStrategyB

33.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Context: setStrategy(strategy)
    Client->>Context: execute()
    Context->>Strategy: algorithm()

33.7 ⚖️ Trade-offs

33.7.1 Advantages ✅

• Encapsulates algorithms
• Runtime algorithm selection
• Eliminates conditionals
• Promotes composition
• Easy to add new strategies

33.7.2 Disadvantages ❌

• Increased number of classes
• Overhead for simple algorithms
• Client must understand strategies
• Context-strategy coupling
• Strategy selection complexity

33.8 🌍 Real-World Use Cases

• Payment methods
• Compression algorithms
• Sorting algorithms
• Search strategies
• Rendering engines

33.9 📚 References

• Gang of Four Design Patterns
• Algorithm encapsulation

34 Template Method Pattern

34.1 📋 Overview

The Template Method pattern defines the skeleton of an algorithm in a base class, letting subclasses override specific steps.

34.2 🎯 Intent

Problem Solved: - Algorithm structure is fixed, but steps vary - Avoid code duplication in algorithm implementations - Control subclass overrides

34.3 👥 Roles & Responsibilities

34.4 💡 Code Example

public abstract class DataProcessor {
    public final void process() {
        readData();
        validateData();
        processData();
        writeData();
    }
    
    abstract void readData();
    abstract void validateData();
    abstract void processData();
    abstract void writeData();
}

public class XMLProcessor extends DataProcessor {
    @Override
    void readData() { /* XML reading */ }
    
    @Override
    void validateData() { /* XML validation */ }
    
    @Override
    void processData() { /* XML processing */ }
    
    @Override
    void writeData() { /* XML writing */ }
}

// Usage
DataProcessor processor = new XMLProcessor();
processor.process();

Reasoning: Defines algorithm structure; lets subclasses implement steps; prevents duplication.

34.5 📊 Class Diagram

classDiagram
    class AbstractClass {
        +templateMethod()
        #primitiveOp1()
        #primitiveOp2()
    }
    class ConcreteClass
    AbstractClass <|-- ConcreteClass

34.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>AbstractClass: templateMethod()
    AbstractClass->>AbstractClass: primitiveOp1()
    AbstractClass->>AbstractClass: primitiveOp2()
    AbstractClass-->>Client: done

34.7 ⚖️ Trade-offs

34.7.1 Advantages ✅

• Code reuse
• Controls extension points
• Defines skeleton once
• Consistent algorithm structure
• Promotes inheritance

34.7.2 Disadvantages ❌

• Inheritance hierarchy required
• Tight coupling between base and derived
• Hollywood Principle violation possible
• Inflexible for diverse algorithms
• Violates Composition over Inheritance

34.8 🌍 Real-World Use Cases

• Framework hook methods
• Stream processing pipelines
• Database connection pooling
• Junit test setup/teardown
• Application lifecycle methods

34.9 📚 References

• Gang of Four Design Patterns
• Template Method variations

35 Visitor Pattern

35.1 📋 Overview

The Visitor pattern represents an operation to be performed on elements of an object structure. It lets you define a new operation without changing the classes of the elements on which it operates.

35.2 🎯 Intent

Problem Solved: - Perform operations on complex object structures without changing their classes - Add new operations to class hierarchy without modification - Operations are related but scattered across classes

35.3 👥 Roles & Responsibilities

35.4 💡 Implementation

Visitor pattern is particularly useful when you have: - Complex object hierarchies requiring multiple operations - Operations that change frequently - Classes that shouldn’t be modified with new methods - Need to gather data from object structure

35.5 📊 Class Diagram

classDiagram
    class Visitor {
        <<interface>>
        +visitConcreteElementA(e)
        +visitConcreteElementB(e)
    }
    class ConcreteVisitor
    class Element {
        <<interface>>
        +accept(v: Visitor)
    }
    class ConcreteElementA
    class ConcreteElementB
    Visitor <|-- ConcreteVisitor
    Element <|-- ConcreteElementA
    Element <|-- ConcreteElementB
    Element --> Visitor

35.6 🔄 Sequence Diagram

sequenceDiagram
    actor Client
    Client->>Element: accept(visitor)
    Element->>Visitor: visit(element)

35.7 ⚖️ Trade-offs

35.7.1 Advantages ✅

• Separates operations from objects
• Easy to add new operations
• Gathers related operations
• Follows Open/Closed Principle
• Centralizes operation logic

35.7.2 Disadvantages ❌

• Difficult to add new element types
• Violates Encapsulation
• Double dispatch complexity
• Hard to understand
• Multiple pass traversals

35.8 🌍 Real-World Use Cases

• Compiler AST visitors
• Document processors
• Report generators
• Tree structure operations
• Metrics collection tools

35.9 📚 References

• Gang of Four Design Patterns
• Compiler design patterns