從討厭分類到改觀：學設計模式的新角度
此為《Learning JavaScript Design Patterns, 2nd Edition》學習筆記，對應第 6 章（Categories of Design Patterns）
我原本對分類的壞印象
過去在其他學習經驗裡，我對「分類法」的印象並不好。常常只是把一堆概念硬切成幾類，看似清楚，卻缺乏實質意義。久而久之，我就先入為主地覺得「分類」是不重要的東西。
但讀完第 6 章後，我才發現這次不太一樣。這裡的分類不是單純在表面上劃分，而是依照「要解決的問題類型」來分的。這讓我換了一個角度去看設計模式：它提醒我，不要只盯著程式碼，還要去想「模式究竟想解決什麼」。
也因為這樣，我開始推演：如果未來在學新模式，或者遇到新的問題，我要怎麼把這些分類用得上？
學習時：先問它想解決什麼問題
未來學習新模式時，我可以先想：它大概屬於哪一類？ 這個小動作，應該能讓我更快抓到重點，而不是被語法細節卡住。
flowchart TB
A["正在學一個設計模式"] --> B{"先判斷它隸屬哪個分類？"}
B -- "建立型（Creational）" --> C1["核心問題：如何生出物件"]
B -- "結構型（Structural）" --> C2["核心問題：物件怎麼拼成結構"]
B -- "行為型（Behavioral）" --> C3["核心問題：物件之間如何互動與分工"]應用時：從問題反推，找到對的工具
如果未來遇到一個問題，我可以先問：核心問題到底在哪裡？ 是要怎麼產生物件？還是要怎麼把物件拼起來？又或者是要讓物件之間協作？
想像中，只要先這樣切一刀，就能把問題對應到分類，再去找合適的模式。
flowchart TB
Q["我現在遇到的問題是什麼？"] --> Q1{"核心問題在哪裡？"}
Q1 -- "如何生出物件？" --> C1["建立型（Creational）"]
Q1 -- "怎麼把物件拼成結構？" --> C2["結構型（Structural）"]
Q1 -- "物件之間怎麼互動、協作、分工？" --> C3["行為型（Behavioral）"]
放在一起看：學習和應用可以對照
如果把兩個角度放在一起，就能看到學習和應用其實是互相呼應的。
flowchart TB
%% 學習導向
subgraph Learn["學習導向"]
L0["學習新的模式時 → 問：它隸屬哪一類？解決的核心問題是什麼？"]:::note
C1[建立型<br/>Creational]:::cat
C2[結構型<br/>Structural]:::cat
C3[行為型<br/>Behavioral]:::cat
end
%% 解決導向
subgraph Apply["應用導向"]
A0["遇到問題時 → 先判斷核心問題，再對應分類"]:::note
Q1["要怎麼產生物件？"]:::q
Q2["要怎麼組合物件？"]:::q
Q3["物件之間要怎麼互動？"]:::q
end
%% 雙向箭頭（互相照應）
Q1 <--> C1
Q2 <--> C2
Q3 <--> C3
%% 樣式
classDef cat fill:#f7f8ff,stroke:#6b7ad7,stroke-width:1px,color:#222b5a;
classDef q fill:#fff7f2,stroke:#d58a66,stroke-width:1px,color:#5a2b1b;
classDef note fill:#fffff0,stroke:#aaa,stroke-dasharray: 3 3,color:#333;到這裡，分類的作用就更清楚了：它其實就是把「問題」和「模式」連接起來的橋樑。
flowchart
subgraph R["模式是怎麼形成的"]
direction TB
A["問題"]:::q --> B["解法 A / B / C"]
B --> E["共通的解法"]
E --> F["設計模式"]:::pattern
E --> G["程式碼怎麼寫"]
end
subgraph L["用分類來理解模式"]
direction TB
Q["問題"]:::q --> QC["問題分類"]
QC --> PC["設計模式分類"]
PC --> P["設計模式"]:::pattern
end
%% 樣式
classDef pattern fill:#f7f8ff,stroke:#6b7ad7,stroke-width:1px,color:#222b5a;
classDef q fill:#fff7f2,stroke:#d58a66,stroke-width:1px,color:#5a2b1b;換句話說：
- 問題會先落在某個「問題分類」
- 模式也對應到一個「設計模式分類」
- 兩邊自然就能連在一起
這樣剛好能接上我之前那篇 《設計模式不是理論，而是經驗語言》 裡畫的『模式如何誕生』流程圖：從問題 → 解法 → 模式。這一篇的分類，剛好補上了另一層：問題的分類，對應到模式的分類。
完整的分類清單（速查用）
把三大類和裡面的模式都攤開來，未來查的時候，就不只是名詞列表，而能直接連到「它大概要解決哪種問題」。
mindmap
((設計模式三大類))
建立型（Creational）
Constructor
Module
Factory Method
Abstract Factory
Builder
Prototype
Singleton
結構型（Structural）
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
行為型（Behavioral）
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor後記：帶著疑問讀書
寫到這裡，我發現這次讀書的收穫，不只是認識分類，而是我對「怎麼學習」這件事有了新的體會。
以前我總是被動地跟著書本章節走，覺得應該要從頭到尾照順序看完才算完整。但這次，我開始意識到：最好的學習方式，或許應該從「提問」開始。先問自己：「為什麼要有這些東西？」而不是急著投入「這些東西是什麼？」的細節裡。
一個例子是，我跳過了書中的第 5 章「現代 JavaScript 語法和特性」。過去的我可能會想「不行，順序很重要，要讀完才完整」。但現在我會反問自己：「這章節能解答我當下的疑惑嗎？它是理解其他內容的關鍵嗎？」當我發現它主要在語法細節，而且暫時不是我最需要的，就選擇先跳過，把精力放在更能建立全貌的分類上。
這樣的調整，讓我不再只是照單全收，而是邊讀邊和內容對話。這次從「分類」開始的探索，也讓我第一次覺得自己手上有了一張清晰的地圖，可以慢慢對照未來要學的模式。