Unlock the Core Logic of Design Patterns: Identify and Encapsulate Change

1. Focus on the Underlying Logic

Design patterns are frequently discussed among developers, but true mastery requires understanding their core logic, not just memorizing their forms.

1. Design Pattern Anecdotes

Two typical jokes illustrate the gap between hearing about patterns and actually applying them: one where a story replaces a pattern, and another where discussions drift from patterns to architecture, then to philosophy.

2. Essence of the Underlying Logic

Just as marketing copy targets a user's pain or pleasure points, design patterns address underlying changes in a system. Recognizing these changes lets you choose the right pattern.

2. The Core Logic of Design Patterns

1. The Foundation

Code can be categorized as spaghetti code, procedural code, or object‑oriented code. Spaghetti code tightly couples logic; procedural code breaks problems into smaller steps; object‑oriented code treats objects as reusable building blocks.

2. The Origin

The classic book "Design Patterns: Elements of Reusable Object‑Oriented Software" emphasizes the mantra “Find the change, encapsulate the change.” This phrase captures the essence of all 23 GoF patterns.

3. Revisiting the Logic

Understanding the underlying logic means identifying what changes and how to encapsulate them, rather than merely learning pattern diagrams.

3. Two Questions Design Patterns Must Answer

1. What Changes?

Changes can occur in object structure, specifications, or behavior. For example, linear relationships (one‑to‑one) and non‑linear relationships (trees, graphs) each present distinct challenges.

2. How to Encapsulate Change

Encapsulation can involve data, methods, or types, using techniques such as configuration, interfaces, abstract classes, inheritance, composition, and principles like Single Responsibility, Open‑Closed, and Dependency Inversion.

4. Deriving Structural Patterns from the Core Logic

1. Detecting Object Structure Changes

Relationships are either linear or non‑linear. Linear changes affect dependent objects directly; non‑linear changes require more sophisticated handling.

2. Handling Linear Changes

Introduce an adapter or proxy so the dependent object does not interact directly with the changing component.

3. Handling Non‑Linear Changes

Use registration mechanisms or façade layers to hide complexity and manage multiple dependent objects.

5. Applying the Logic to Business Changes

When building payment integrations, treat each payment channel as a concrete implementation of a common abstract template, allowing new channels to be added with minimal code changes.

6. Principles of Object Design

Ask three questions: What objects exist? How are they related? What responsibilities do they have? Answering these leads to a clear, extensible object model.

7. A Real‑World Case: Shop Category Model

Design a flexible model that supports varying category hierarchies and dynamic product selection criteria (price, launch time, rating). The initial version introduced separate root and sub‑category concepts, which later were merged to simplify the code.