本章主軸#

本章正式介紹設計模式（design patterns）的概念：它們從哪裡來、為什麼值得學、又能帶給軟體開發者什麼樣的長期能力。

過去常有人說「先精通物件導向再來學設計模式」。作者的經驗剛好相反：愈早接觸設計模式，物件導向反而學得愈深愈快。

設計模式的源頭：建築與人類學#

Christopher Alexander 的提問：品質可以客觀嗎？#

建築師 Christopher Alexander 想知道：「美」與「品質」是否客觀？他相信在建築領域內，存在著可被描述的客觀基礎。

• 文化人類學的研究也指出：同一文化內，人們對「好設計」會有相當高的共識
• Alexander 觀察建築、城鎮、街道後發現，好的結構彼此之間具備可辨識的共同點
• 同一個問題可有不同形式的好解法（例如不同樣式的門廊都可優雅地完成「過渡」這個任務）

模式的定義#

Alexander 把「在某個情境中針對重複出現問題的解法核心」稱為「模式」：

每個模式描述一個在我們環境中反覆出現的問題，並給出該問題核心的解法，使我們得以重複使用這個解法上百萬次，卻不必每次以同樣方式實作。

一個模式的四個要件#

• 名字
• 目的：模式所要解決的問題
• 如何解：解法的核心
• 力量與限制：實作時必須權衡的張力（forces）與條件

從建築模式到軟體模式#

1990 年代初，幾位開發者把 Alexander 的思路引入軟體：

• 軟體中是否存在反覆出現、可用相似方式解決的問題？
• 是否能在識別出模式後再做設計？

Gamma、Helm、Johnson、Vlissides 四人合著的《Design Patterns: Elements of Reusable Object-Oriented Software》是奠基之作，他們被尊稱為 Gang of Four（GoF）。書中編目了 23 個模式，並提出物件導向的設計策略。

GoF 並不是「發明」這些模式，而是整理已存在於社群中的優良解法。

模式描述的主要欄位#

「Consequences」一詞容易被誤解為「壞處」。在模式社群裡，它泛指因果關係——使用此模式會如何影響並被力量所影響。

為什麼要學設計模式？#

常被提到的理由：

• 重用解法：站在前人的肩膀上避開地雷
• 建立共同詞彙：團隊溝通與設計討論的共同語言

但更深層的價值是：

• 拉高思考層次：擺脫過早陷入細節的暴政
• 判斷設計品質：不只是「能跑」，而是「設計對不對」
• 促進個人與團隊的學習
• 讓程式碼更易修改、更易維護
• 內化原則，即使不直接套用模式，也能寫出更好的設計
• 避免巨大的繼承樹

兩個木匠的對話：細節暴政#

書中以兩位木匠討論抽屜接合方式為例：

• 木匠 2 詳述刀具如何切割：垂直下、45 度上、再下、再 45 度 ⋯⋯ 聽不懂在做什麼
• 木匠 1 直接問：「我們用 dovetail（鳩尾榫）還是 miter（斜接）？」

差別在於思考層次：

真正的對話是在權衡品質與成本，而不是切刀步驟。

設計模式讓設計師擁有同等級的「meta 對話」語言，避免被細節吞沒。

GoF 提出的核心策略#

• Design to interfaces（面向介面設計）
• Favor aggregation over inheritance（偏好聚合勝於繼承）
• Find what varies and encapsulate it（找出變動點並封裝）

即使你只學會幾個模式，也應該透過它們去吸收背後這些原則——這才是長久受用的部分。

本章重點#

• 設計模式源於 Alexander 對建築品質的研究
• 模式不是僵化模板，而是「在某情境下解決某問題」的核心方案
• 學習模式的最大收穫不在背下幾個結構，而在內化背後的原則
• 模式幫助設計師擺脫細節暴政，建立 meta 級的設計對話