Choosing Design Patterns Wisely

1. A Framework for Choosing Patterns

With over 23 patterns in the original "Gang of Four" book, how do you even begin to choose? The first step is to identify the fundamental nature of the design problem you're trying to solve. Does your problem concern object creation, the composition of objects, or the interaction between them?

This leads to the three main categories we've discussed:

• Creational Patterns: Deal with object instantiation mechanisms, trying to create objects in a manner suitable to the situation.
• Structural Patterns: Deal with object composition, forming larger structures from individual parts.
• Behavioral Patterns: Deal with communication between objects, their responsibilities, and the algorithms they use.

To go from this high-level map to a concrete choice, we need a more detailed guide.

The checklist you just read provides a great strategic overview. To summarize, your process should be:

1. Identify the Problem Type: Is it creational, structural, or behavioral?
2. Assess Scalability & Complexity: Will the pattern support future growth without being overly complex for the current problem?
3. Consider Team Expertise: Is this a pattern your team can easily understand and maintain?
4. Prototype and Test: Does the pattern actually solve the problem elegantly in practice?

2. A Heuristic Approach: Asking the Right Questions

The framework above is a great start. Now, let's get more tactical. How do you map a problem description to a specific pattern? Often, it comes down to asking the right questions about what needs to be flexible or what needs to be encapsulated.

The following resource offers a brilliant, question-based guide to finding patterns.

Let's distill those heuristics into a mental model:

• Are you trying to manage how objects are created?
  • Do you need to create families of related objects? → Abstract Factory
  • Do you need to construct a complex object step-by-step? → Builder
  • Do you want subclasses to decide which class to instantiate? → Factory Method
  • Do you need to ensure only one instance of an object exists? → Singleton
• Are you trying to manage the structure of your classes and objects?
  • Do you need to make an existing class's interface match what a client expects? → Adapter
  • Do you want to provide a single, simplified interface to a complex subsystem? → Facade
  • Do you need to add new responsibilities to an object dynamically? → Decorator
  • Do you want to treat a group of objects the same way as a single object? → Composite
• Are you trying to manage the behavior and communication between objects?
  • Do you need a list of objects to be notified when a state changes? → Observer
  • Do you need to select an algorithm at runtime? → Strategy
  • Do you need to encapsulate a request as an object (e.g., for queues or undo)? → Command
  • Do you want to reduce coupling between many objects by having them communicate through a central point? → Mediator

This question-driven approach helps you quickly narrow down the possibilities from 23 to a handful of likely candidates.

3. Justifying Your Choice by Comparing Alternatives

Selecting a pattern is half the battle. Justifying it is what demonstrates deep understanding. This often involves explaining why you chose pattern A instead of pattern B, especially when they seem similar.

For example, Adapter, Facade, Proxy, and Decorator are all "wrapper" patterns. How do you choose? It comes down to intent.

Let's return to the "Design Pattern Matrix" to see how to differentiate them.

Here's a summary of the key distinctions based on their intent:

Being able to articulate these differences is a hallmark of a good software architect.

4. Case Study: Designing a Notification System

Let's apply this framework to a practical problem.

Scenario: You are designing a notification system for an e-commerce platform.

• The system must send a notification when an order is shipped.
• Initially, it only needs to send emails.
• In the future, it will need to support SMS and in-app push notifications.
• A user should be able to select their preferred notification method. Eventually, they might want to receive notifications through multiple channels (e.g., email and SMS).
• The core OrderService should not have to be modified every time a new notification channel is added.

Let's walk through the decision process:

1. Identify the Problem Type: The core of the problem is about handling different ways of doing something (sending a notification) and swapping them based on user preference. This is a classic Behavioral problem. We also need to create the right notification sender, which hints at a Creational pattern.

2. Ask the Right Questions:

   • "Is there variation of a business rule or an implementation?" Yes, the notification logic varies. The heuristic guide points to the Strategy pattern. We can define an INotifier interface and have EmailNotifier, SmsNotifier, etc., as concrete strategies.
   • "Do we need to add some function?" Yes, users might want to combine notification channels. The guide suggests Decorator to add multiple functions. We could have a MultiChannelNotifier that wraps several INotifier instances.
   • "Are we trying to make things?" Yes, we need to create the correct notifier object based on user settings. This suggests a Factory pattern (either Factory Method or Abstract Factory) to encapsulate the creation logic.

3. Synthesize and Justify:
   A combination of patterns seems ideal here.

   • Strategy is the core. It allows the OrderService to depend on the INotifier interface, upholding the Open/Closed Principle. The service can execute a notification strategy without knowing its concrete type.
   • Factory is needed to instantiate the correct strategy. The OrderService shouldn't contain a switch statement to decide which notifier to create. Instead, it can ask a NotifierFactory to provide the correct object based on the user's preferences.
   • Decorator could be used to handle the requirement of multiple channels. A SmsAndEmailNotifier could be a decorator that holds both an SmsNotifier and an EmailNotifier.

This combination of Strategy and Factory is extremely common and powerful. Let's see it in action.

abstract class DataExporter {
    // The template method
    public final File export() {
        Data data = fetchData();
        FormattedData formatted = formatData(data);
        File file = generateFile(formatted);
        return file;
    }

    // Common step implemented in the base class
    private Data fetchData() {
        // ... logic to fetch data from DB
    }

    // Steps to be implemented by subclasses
    protected abstract FormattedData formatData(Data data);
    protected abstract File generateFile(FormattedData formatted);
}

Conclusion

You've now reached a significant milestone in your journey toward an architectural mindset. Choosing the right design pattern is not about memorization; it's a process of systematic analysis, questioning, and justification.

Key Takeaways:

• Analyze First: Start by identifying the core intent of your design problem: Is it about creation, structure, or behavior?
• Use Heuristics: Use question-based guides and pattern catalogs to narrow down your options to a few likely candidates.
• Compare and Justify: For similar patterns, focus on their specific intent to justify your choice. Articulating the "why" is as important as the "what."
• Combine Patterns: Real-world problems often require combining multiple patterns (like Strategy and Factory) to create a robust and flexible solution.

Preview of the Next Lesson:
This lesson concludes our module on code-level design patterns. We will now move up a level of abstraction to system-level architecture. In the next module, "Database Architecture & Design," our first lesson will be on the CAP Theorem. This fundamental principle governs the trade-offs in distributed database systems and will be your first step into designing for large-scale, resilient data storage.