Design Patterns 23 – Final Overview: Mapping All 23 Patterns onto One Diagram

1. Patterns Hidden in Everyday Code

Recognizing design patterns in the source code of frameworks is the most effective way to learn them. The author lists concrete JDK examples such as Runtime.getRuntime() (Singleton), Calendar.getInstance() (Factory), StringBuilder (Builder), Object.clone() (Prototype), InputStreamReader (Adapter), java.io.BufferedInputStream (Decorator), Integer cache (Flyweight), java.lang.reflect.Proxy (Proxy), Iterator / Iterable (Iterator), java.util.Observer (Observer), AbstractList (Template Method), Runnable (Command), and Servlet Filter (Chain of Responsibility), among others.

Spring reuses almost all patterns: Bean default scope (Singleton), BeanFactory / FactoryBean (Factory), AOP proxies for @Transactional and @Cacheable (Proxy), JdbcTemplate and RestTemplate (Template Method), ApplicationEvent + @EventListener (Observer), HandlerAdapter (Adapter), HandlerInterceptor (Chain), Resource loading (Strategy), BeanWrapper / Wrapper (Decorator), and a Facade for complex subsystems.

MyBatis also demonstrates Builder ( SqlSessionFactoryBuilder), Proxy (dynamic proxy for mapper interfaces), and Factory ( SqlSessionFactory).

These examples illustrate two key takeaways: developers have been using design patterns all along without realizing it, and understanding these patterns is essential for reading and reasoning about framework designs.

2. Frequently Confused Pattern Pairs

Factory vs Builder – Factory decides *which* type to create; Builder assembles a single object step‑by‑step.

Factory Method vs Abstract Factory – Factory Method creates one product; Abstract Factory creates a whole family of related products.

Proxy vs Decorator – Proxy controls access; Decorator adds functionality while keeping the original interface.

Decorator vs Adapter – Decorator enhances without changing the interface; Adapter changes the interface to make incompatible components work together.

Proxy vs Adapter vs Decorator – Only Adapter modifies the interface; Proxy and Decorator keep it unchanged.

Strategy vs State – Strategy selects one algorithm among many; State changes behavior according to internal rules and is best represented with a state diagram.

Strategy vs Template Method – Strategy swaps the whole algorithm via composition; Template Method swaps only selected steps via inheritance.

Command vs Memento – Command records an inverse operation (incremental); Memento stores a full snapshot.

Facade vs Mediator – Facade provides a one‑way simplified interface; Mediator coordinates two‑way interactions among components.

Bridge vs Strategy – Bridge separates two long‑evolving dimensions; Strategy replaces a single algorithm.

The common thread is that many patterns share almost identical class diagrams; the real distinction lies in intent—what problem the pattern is meant to solve.

3. Over‑Design and Proper Use of Patterns

The author reiterates the most important lesson: the biggest risk after learning the 23 patterns is not “not knowing how to use them” but “using them everywhere.” New learners often see every piece of code as insufficiently elegant and start inserting patterns indiscriminately—e.g., adding a Factory for a single‑implementation interface, breaking a simple two‑branch conditional into a Strategy, or wrapping a three‑field object with a Builder. Such gratuitous use makes code harder to maintain than plain code.

Key guidelines:

Use a pattern only to solve a *real* variation, not to showcase skill.

Apply YAGNI: avoid abstracting for imagined future extensions that may never materialize.

If a simple if‑else, direct new, or ordinary method suffices, keep it; simplicity is a sign of good design.

Introduce a pattern during refactoring, after the plain code becomes painful due to growing complexity.

The ultimate goal is to use the simplest structure that adequately addresses the current problem while leaving room for the identified, concrete changes.

4. A Panoramic Map Linking the 23 Patterns to the Seven Principles

The series concludes with a visual map (image omitted) that places each of the 23 GoF patterns under the three categories (Creational, Structural, Behavioral) and annotates them with the design principle they primarily embody. All patterns stem from the seven principles, especially “Composition over Inheritance” and “Program to an Interface / Dependency Inversion.”

Four overarching observations derived from the map:

“Composition over Inheritance” is the soul of structural patterns; most of them replace inheritance with object composition.

“Program to an Interface + Dependency Inversion” underpins almost every pattern, encouraging reliance on abstractions rather than concrete implementations.

“Isolate the points of change” is the common purpose: each pattern first identifies what may vary (creation, algorithm, interface, state) and then abstracts that variation.

The “Open‑Closed Principle” is the desired effect: after applying a pattern, new functionality can be added without modifying existing code.

In summary, the 23 patterns are not isolated tricks but the concrete fruits of seven principles aimed at handling change and reducing coupling. Mastery lies in the mindset “recognize change → abstract the variation → program to an interface → prefer composition,” not merely in memorizing individual pattern templates.