設計模式的本質
設計模式非炒作、非玩具，而是經驗證證的設計智慧具名封裝。如同演算法領域的「快速排序」、「二分搜尋」提供共享詞彙與複雜度保證，設計模式為物件導向設計提供：
- 共享詞彙：說「Bridge 模式」即知介面與實作分離、執行期開銷、原始碼佈局建議。
- 高效溝通：避免低層級、冗長、模糊的設計描述。
- 有效評議：同事能即時指出模式適用性（如單向鏈表不宜用 Quick Sort）。
模式描述四要素（GoF 結構）
- 名字：無歧義（Wrapper 太泛，細分為 Bridge/Strategy/Facade/Adapter）。
- 問題：特定情境下的設計挑戰。
- 解決方案：可依情境定制的通用結構。
- 後果：權衡分析（效能、耦合、複雜度、擴充性）。
模式即「微架構」與「輔助定理」
組合模式生成架構，如同數學證明組合輔助定理：
- 天才可從公理推導，但常人（含專家）靠模式更高效、溝通更順暢。
- 模式知識不保證設計成功，但能理解他人設計、避免重造輪子。
- 經理若懂模式詞彙，亦能審閱架構文件。
常見誤區澄清
| 誤區 | 真相 |
|---|
| 模式 = 複雜 | 模式簡化溝通，實作可極簡（如 Singleton 幾行碼） |
| 套用越多越好 | 過度設計是大忌，需依情境權衡後果 |
| 模式限制創新 | 模式是詞彙非法條，創新往往源於組合/變體 |
| 只懂 GoF 23 個 | 架構模式、並發模式、領域模式同樣重要 |
實戰建議
- 建立團隊模式詞彙表，Code Review 時要求標註模式名稱。
- 文件化架構決策時，明確記錄：採用模式、動機、替代方案、已知後果。
- 重構時以模式為目標（如「將此處改為 Strategy 模式」），而非模糊的「改善設計」。
- 學習新模式：先理解問題與後果，再記結構，最後練習變體實作。
