Problem: Creating Objects?
├─ Single instance needed? → Singleton
├─ Complex construction? → Builder
├─ Type varies by input? → Factory Method
└─ Expensive creation? → Prototype

Problem: Object Structure?
├─ Add behavior dynamically? → Decorator
├─ Incompatible interfaces? → Adapter
├─ Simplify complex system? → Facade
├─ Control access? → Proxy
└─ Tree structure? → Composite

Problem: Object Behavior?
├─ State-dependent? → State
├─ Interchangeable algorithms? → Strategy
├─ Notify many objects? → Observer
├─ Encapsulate requests? → Command
├─ Fixed algorithm steps? → Template Method
└─ Chain of handlers? → Chain of Responsibility

## Recommended Pattern: [Pattern Name]

**Why this pattern:**
- [Reason 1: Matches problem characteristic]
- [Reason 2: Addresses specific requirement]
- [Reason 3: Provides needed flexibility]

**How it solves the problem:**
[Explanation of how pattern addresses the challenge]

**Implementation approach:**
[Code example or structure diagram]

**Benefits:**
- [Benefit 1]
- [Benefit 2]
- [Benefit 3]

**Trade-offs:**
- [Trade-off 1]
- [Trade-off 2]

## Recommended Pattern: Strategy

**Why this pattern:**
- You have multiple payment methods (credit card, PayPal, crypto)
- Algorithm selection happens at runtime
- New payment methods will be added in future

**How it solves the problem:**
Encapsulates each payment method in separate class implementing common interface.
Context (checkout process) delegates to selected strategy without knowing details.

**Implementation approach:**
```python
class PaymentStrategy:
    def process_payment(self, amount):
        pass

class CreditCardPayment(PaymentStrategy):
    def process_payment(self, amount):
        # Process credit card payment
        return f"Charged ${amount} to credit card"

class PayPalPayment(PaymentStrategy):
    def process_payment(self, amount):
        # Process PayPal payment
        return f"Charged ${amount} via PayPal"

class Checkout:
    def __init__(self, payment_strategy):
        self.payment_strategy = payment_strategy

    def complete_purchase(self, amount):
        return self.payment_strategy.process_payment(amount)

# Usage
checkout = Checkout(CreditCardPayment())
checkout.complete_purchase(99.99)

### Step 5: Provide Alternatives

Suggest 1-2 alternative patterns with comparison:

```markdown
## Alternative Patterns

### Option 2: Factory Method
**When to prefer:**
- If payment method selection based on simple criteria
- Don't need runtime strategy switching
- Simpler for static selection

**Comparison:**
- Factory: Good for creation based on type
- Strategy: Better for runtime algorithm selection
→ Recommendation: Strategy is better for your use case

### Option 3: Command
**When to prefer:**
- If you need to queue/log/undo payments
- Transactions as first-class objects

**Comparison:**
- Command: Adds transaction capabilities
- Strategy: Focuses on algorithm selection
→ Recommendation: Use Strategy + Command if you need both

## Pattern Combination

Your scenario benefits from combining:

1. **Strategy** for payment methods
2. **Factory** for creating appropriate strategy
3. **Decorator** for adding features (logging, validation)

**Architecture:**

**Implementation order:**
1. Start with Strategy (core pattern)
2. Add Factory if strategy selection is complex
3. Add Decorator for cross-cutting concerns

# Python: Use ABC for interfaces
from abc import ABC, abstractmethod

class Strategy(ABC):
    @abstractmethod
    def execute(self):
        pass

// TypeScript: Use interfaces
interface Strategy {
    execute(): void;
}

class ConcreteStrategy implements Strategy {
    execute(): void {
        // Implementation
    }
}

// Java: Use interfaces or abstract classes
interface Strategy {
    void execute();
}

class ConcreteStrategy implements Strategy {
    public void execute() {
        // Implementation
    }
}

Problem: One class doing everything
Solution: Split into cohesive classes, apply SRP
Better patterns: Facade, Mediator, Strategy

Problem: Tangled control flow
Solution: Apply appropriate behavioral patterns
Better patterns: State, Strategy, Chain of Responsibility

Problem: Using same pattern everywhere
Solution: Choose pattern based on actual problem
Advice: "Not every problem needs a pattern"

Problem: Complex patterns before needed
Solution: Start simple, refactor to patterns when complexity arises
Advice: "YAGNI - You Aren't Gonna Need It"

Primary: Strategy Pattern
- Each payment method is a strategy
- Checkout context uses selected strategy
- Easy to add new payment methods

Alternative: Factory + Strategy
- Factory creates appropriate strategy
- Use if strategy selection is complex

Code structure:
- PaymentStrategy interface
- CreditCardPayment, PayPalPayment, CryptoPayment classes
- Checkout class with injected strategy

Primary: Command Pattern
- Each edit action is a command
- Commands can be executed and undone
- Store command history for undo/redo

Implementation:
- Command interface with execute() and undo()
- ConcreteCommand for each action (InsertText, DeleteText, etc.)
- CommandHistory manages undo/redo stack

Bonus: Combine with Memento for complex state

Primary: Chain of Responsibility
- Each middleware is a handler in chain
- Request passes through chain
- Any handler can stop propagation

Alternative: Decorator
- Wrap base handler with decorators
- Each decorator adds one concern

Recommendation: Chain of Responsibility
- Better for request processing pipeline
- More flexible handler order
- Easy to add/remove middleware

Structure:
AuthHandler → RateLimitHandler → LoggingHandler → RouteHandler