範式是「把輸入轉成輸出」的不同思維框架。命令式問「怎麼做（How）」、宣告式問「做什麼（What）」；OOP 把系統看成一群協作的物件。理解每種範式的本質與擅長的問題，才知道一個 GoF 模式在補哪個範式的缺口——這是整個 paradigms 類別的地圖。
🧠 When to Use
TIP
訊號：你在爭論「這段該寫成物件還是函數管線」——先退一步看範式本質：這個問題是「設計指令」「設計函數」還是「設計協作的物件」比較自然?
- 判斷手上的問題最適合哪種範式來表達。
- 看懂設計模式時，先辨識它服務於哪個範式、補了什麼缺口。
- 在混合範式語言裡，替不同子問題挑不同範式，並劃清邊界。
⚖️ Structure & Variants
三大核心範式的本質
| 範式 | 程式本質 | 輸入 → 輸出 | 設計重點 | 運行機制 |
|---|---|---|---|---|
| 命令式 | 自動機 | 初始狀態 → 最終狀態 | 設計指令 | 執行命令 |
| 函數式 | 數學函數 | 自變數 → 應變數 | 設計函數 | 運算式變換 |
| 邏輯式 | 邏輯證明 | 假設 → 結論 | 設計命題 | 邏輯推理 |
- 命令式問「怎麼做（How）」：變數是可變的記憶體、有賦值、邏輯路徑顯性可見（C、早期 Java）。其骨架是結構化定理——任何邏輯都能由循序 / 選擇 / 迴圈組成，並摒棄
goto。 - 宣告式問「做什麼（What）」：變數像數學常數（不可變）、演算法隱含在引擎裡、程式碼即規格（SQL、HTML、Haskell）。它分兩支：函數式（運算式變換求值）與邏輯式（事實 + 規則推導）。
OOP：把系統看成協作的物件
三大支柱：
- 封裝＝個體的邊界：隱藏內部、只經公開方法溝通，保護狀態不被外力篡改。
- 繼承＝血緣傳承：承接父類特徵，達成重用（但注意過度繼承的代價，見組合優於繼承）。
- 多型＝角色扮演：同一介面依實際物件展現不同行為，是絕大多數 GoF 模式的支點。
程序式 vs 物件式，是「君主制 vs 民主制」：
- 程序式（Top-Down）：邏輯凌駕一切，資料是被動臣民；主流程一變，全局脆弱。
- 物件式（Bottom-Up）：資料與行為封裝於個體，局部變動由個體吸收，整體較強韌、易橫向擴展。
觀念導正：OOP 並非萬能、不能脫離其他範式；它的真正優勢與其說是「重用性」，不如說是**「易用性」**。
常用衍生範式 —— 都對應到某些設計模式
⚠️ Misuse & Anti-patterns
- 範式教條主義：把「萬物皆物件」或「萬物皆純函數」硬套到不合適的問題上。
- 誤以為某優點是 OOP 獨有：可維護性、擴充性是所有範式的共同目標，不是 OOP 專利。
- 混用無邊界：同一模組半 OO 半 FP 又不劃清界線，讀者得不斷切換心智模型。範式可混，但要有邊界。
- 背模式而不辨範式：不先問模式服務哪個範式、補什麼缺口，就機械套用，常在有一級函數的語言裡多繞一層。
🔑 Takeaways
- 範式＝「輸入→輸出」的不同思維：命令式（How）／函數式・邏輯式（What）／物件式（協作）。
- 命令式的骨架是結構化定理（循序/選擇/迴圈）；宣告式的變數像常數、程式即規格。
- OOP 三支柱＝封裝（邊界）／繼承（傳承）／多型（角色），多型是 GoF 模式的支點；OOP 的長處是易用性而非萬能。
- 衍生範式各對應模式家族：泛型→Iterator、事件驅動→Observer + IoC/DI、AOP→橫切關注點。
No notes yet — jot your takeaways or Q&A here.