關於 Comparison of Design Patterns 本篇將討論以下幾個問題
1. 前言
2. 三大分類各自的意圖
3. Comparison
1. 前言
Design Patterns 這系列終於到了最後一篇，經過前面一連串的洗禮後是否覺得每個 Pattern 個別理解都沒什麼問題，但參在一起做撒尿牛丸又說不太出其間的差異呢？
每個 Design Pattern 都有其想解決的問題跟使用上的缺陷，所以在能夠靈活運用之前，有些方法可以幫助我們找到適合的 Pattern
- 釐清目前想解決的問題
- 依據 Pattern 的「意圖」來尋找適合的 Pattern
- 套用時若需要變形，是否會有什麼新的缺點
- 套用後是否有明顯的好處，且大於缺點
一一確認完之後，除了能更加熟悉之外，也避免了為套用而套用造成的系統複雜度提升跟擴充困難的問題。
但若是因為未來還不確定的需求而不知道該不該套用，我的建議是：未來的需求就交給重構來解決，專注於當下的問題即可。
2. 三大分類各自的意圖
| 類型 | |
|---|---|
| 創建型 | 負責物件的創建，將創建與使用解耦 |
| 結構型 | class 或物件的組合，將不同的職責解耦 |
| 行為型 | class 或物件間的交互行為，將不同的行為解耦 |
3. Comparison
| ● 創建複雜物件 | |
|---|---|
| Abstract Factory(抽象工廠) | 創建包含一系列彼此關聯的物件 |
| Builder(建造者) | 創建過程複雜物件 |
| Factory Method(工廠方法) | 創建複數個複雜物件 |
| Prototype(原型) | 創建成本較高物件 |
-
| ● 創建唯一物件 | |
|---|---|
| Singleton(單例) | 保證物件全局唯一 |
-
| ● 物件對接 | |
|---|---|
| Adapter(轉接器) | 接口無法對應問題，改變原始 class 接口 |
| Bridge(橋接) | 分離接口與實作，複雜物件間的組合 |
| Decorator(裝飾者) | 不改變原始 class 接口條件下，增強原有功能 |
| Facade(門面) | 整合多個接口 |
| Proxy(代理) | 控制訪問，而非加強功能 |
| Mediator(中介者) | 物件間複雜相依邏輯，包含雙向關係 |
-
| ● 兩個維度 | |
|---|---|
| Bridge(橋接) | 兩個維度皆可擴充 |
| Visitor(訪問者) | 其中一個維度固定 |
-
| ● 接收與發送行為 | |
|---|---|
| Chain of Responsibility(責任鏈) | 依序將請求傳遞給接續處理物件 |
| Command(命令) | 單方面將請求發送給處理者 |
| Mediator(中介者) | 物件間複雜相依邏輯，包含雙向關係 |
| Observer(觀察者) | 處理者動態決定是否接收請求 |
-
| ● 依序處理 | |
|---|---|
| Decorator(裝飾者) | 依序處理，全部完成才結束，無法中斷 |
| Chain of Responsibility(責任鏈) | 依序處理，目的達成即結束 |
-
| ● 呼叫端指定 | |
|---|---|
| Command(命令) | 控制行為(e.g. 執行、取消) |
| Strategy(策略) | 提供選擇，由呼叫端選擇程式中部分執行邏輯 |
-
| ● 邏輯抽換 | |
|---|---|
| Strategy(策略) | 基於組合 |
| Template Method(樣板方法) | 基於繼承 |
-
| ● 狀態變換 | |
|---|---|
| Memento(備忘錄) | 紀錄物件本身狀態提供還原 |
| State(狀態) | 依據呼叫端狀態，大量 if/else 時的解決方案 |
-
| ● 大量物件 | |
|---|---|
| Flyweight(享元) | 大量高度相似物件複用，節省記憶體 |
-
| ● 特殊結構 | |
|---|---|
| Composite(組合) | 樹狀結構 |
| Interpreter(直譯器) | 依據已定義邏輯進行複雜轉換 |
| Iterator(迭代器) | 常與其他模式搭配 1. with Composite(組合)：遍歷樹狀結構 2. with Memento(備忘錄)：遍歷已備份狀態 |
