27. Comparison of Design Patterns


Posted by WayneCheng on 2021-02-07

關於 Comparison of Design Patterns 本篇將討論以下幾個問題

1. 前言

2. 三大分類各自的意圖

3. Comparison


1. 前言

Design Patterns 這系列終於到了最後一篇,經過前面一連串的洗禮後是否覺得每個 Pattern 個別理解都沒什麼問題,但參在一起做撒尿牛丸又說不太出其間的差異呢?

每個 Design Pattern 都有其想解決的問題跟使用上的缺陷,所以在能夠靈活運用之前,有些方法可以幫助我們找到適合的 Pattern

  1. 釐清目前想解決的問題
  2. 依據 Pattern 的「意圖」來尋找適合的 Pattern
  3. 套用時若需要變形,是否會有什麼新的缺點
  4. 套用後是否有明顯的好處,且大於缺點

一一確認完之後,除了能更加熟悉之外,也避免了為套用而套用造成的系統複雜度提升跟擴充困難的問題。

但若是因為未來還不確定的需求而不知道該不該套用,我的建議是:未來的需求就交給重構來解決,專注於當下的問題即可。


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(備忘錄):遍歷已備份狀態

總結

Design Patterns 應用的深度與廣度都不是看完本系列就能掌握的,還有很多細節的應用並未提及,全篇都圍繞在基本概念的理解上,至此相信已經能解決部分問題了,若是想更深入學習 Design Patterns 可以購買書籍來閱讀,推薦以下兩本。

大話設計模式

深入淺出設計模式 (Head First Design Patterns)


參考資料

  1. Design Patterns
  2. 大話設計模式
  3. dofactory
  4. Refactoring.Guru

新手上路,若有錯誤還請告知,謝謝


#designpattern







Related Posts

TEST

TEST

股癌

股癌

同步 & 非同步(3) - Promise

同步 & 非同步(3) - Promise


Comments