設計模式完整介紹：四人幫（GoF）的 23 種設計模式

什麼是設計模式

設計模式不是函式庫，也不是可以直接複製貼上的程式碼。它是對「反覆出現的問題」、「解法的核心」以及「採用後的取捨」所做的描述。實際的程式碼仍須由你依照所用的程式語言與專案自行撰寫。

GoF 這本書以四個基本要素來描述每一種模式：

• 名稱：一兩個字就能讓開發者討論設計，例如「我們可以用 Decorator 把它包起來」。
• 問題：什麼時候該使用這個模式，以及促使你需要它的情境。
• 解法：涉及的類別或物件、各自的職責，以及它們如何協作。
• 效果：成本與好處，例如以更多類別換取更高的彈性。

這個概念源自建築領域。Christopher Alexander 在 1977 年出版的《A Pattern Language》描述了建築與城鎮中反覆出現的解法，GoF 的作者們便把同樣的想法應用到物件導向軟體上。

四人幫（GoF）這本書

《Design Patterns: Elements of Reusable Object-Oriented Software》由 Addison-Wesley 於 1994 年出版。書中範例使用 C++ 與 Smalltalk，但這些模式適用於任何物件導向語言，包括 Java、C#、TypeScript、Python 和 Kotlin。

除了模式目錄之外，這本書還提出貫穿多數模式的兩項通用原則：

• 針對介面寫程式，而不是針對實作。程式碼應該依賴物件「能做什麼」，而不是它的具體類別。
• 優先使用物件組合，而非類別繼承。以組合物件來建立行為，通常比建立很深的類別階層更有彈性。

書中也依「作用範圍」替每種模式分類：類別模式使用繼承，在編譯期就已固定（Factory Method、類別版 Adapter、Interpreter、Template Method）；物件模式使用組合，可以在執行期改變（其餘所有模式）。

依分類列出 GoF 的 23 種模式

建立型模式處理物件如何被建立；結構型模式處理類別與物件如何組合成更大的結構；行為型模式處理物件之間如何溝通並分擔職責。

實戰中的模式：以 TypeScript 實作 Strategy

下面用一個小例子示範模式的實際運作。結帳流程需要用不同方式計算運費。與其寫一長串越來越冗長的 if/else，不如把每條規則都做成同一介面下可互換的物件：

interface ShippingStrategy {
  cost(weightKg: number): number;
}
class FlatRate implements ShippingStrategy {
  cost(): number { return 5; }
}
class PerKilogram implements ShippingStrategy {
  cost(weightKg: number): number { return 2 * weightKg; }
}
class Checkout {
  constructor(private shipping: ShippingStrategy) {}
  setShipping(s: ShippingStrategy): void { this.shipping = s; }
  total(itemsPrice: number, weightKg: number): number {
    return itemsPrice + this.shipping.cost(weightKg);
  }
}
const checkout = new Checkout(new FlatRate());
console.log(checkout.total(40, 3)); // 45
checkout.setShipping(new PerKilogram());
console.log(checkout.total(40, 3)); // 46

在 TypeScript 中，函式本身就是值，所以同樣的設計可以用更少的程式碼表達。這是個常見的主題：在支援一級函式（first-class functions）的語言中，許多模式會變得更簡單，甚至不再需要。

type Shipping = (weightKg: number) => number;
const flatRate: Shipping = () => 5;
const perKilogram: Shipping = (w) => 2 * w;
function total(itemsPrice: number, weightKg: number, shipping: Shipping): number {
  return itemsPrice + shipping(weightKg);
}
console.log(total(40, 3, flatRate));    // 45
console.log(total(40, 3, perKilogram)); // 46

如何選擇設計模式

一律從問題出發，而不是從模式出發。只有當模式能解決程式碼中真正的痛點時，它多出來的類別才值得。下列問題可以指出常見的候選模式：

1. 先寫出最簡單、能運作的程式碼。
2. 當同一種修改一再造成困擾時（例如每新增一種付款方式就要修改五個檔案），先把問題講清楚。
3. 查閱能解決該問題的模式，並仔細閱讀它們的效果與取捨。
4. 採用能消除痛點的最小版本模式，到此為止。

批評與限制

設計模式很有用，但常被誤用。以下常見的批評值得了解：

• 過度使用：為了「以防萬一」而加入工廠、介面與各種管理器，會讓簡單的程式碼難以閱讀，這有時被稱為「模式狂熱」（pattern fever）。
• 缺少語言特性：Peter Norvig 在 1996 年指出，GoF 的 23 種模式中有 16 種在 Lisp、Dylan 等動態語言中是不可見的，或是變得更簡單。一級函式可以取代 Strategy 與 Command，內建的迭代器則取代了 Iterator。
• 尤其是 Singleton，當它被當成全域狀態使用時，普遍被視為反模式，因為它會隱藏相依關係，並讓測試更困難。
• 這份目錄成形於 1994 年。後來的實務又出現了書中沒有的其他知名模式，例如相依注入（dependency injection）、Repository，以及各種 Model-View-Controller 變體。

這本書長久的價值在於它提供的語彙，以及思考取捨的習慣。對另一位開發者說一句「這是個 Adapter」，短短幾個字就能傳達很多資訊。

相關原則

設計模式經常與物件導向設計的 SOLID 原則一起說明。例如 Strategy 與 Decorator 是實踐開放封閉原則的直接方式，而 Abstract Factory 則是應用相依反轉原則的常見做法。了解這些原則，有助於理解模式為什麼會是現在這個樣子。