設計模式總論

設計模式的作用

• 對重複的問題，利用OOD原則設計出一個強內聚、低耦合的解決方案

設計模式

• 每一種模式都描述一種重複出現的問題的通用解決方案

• 一種可重複使用的解決方案

設計模式四個部分

• 模式名稱

• 名稱有助於表達設計

• 待解問題

• 描述何時運用這種模式，及運用模式的環境(上下文)

• 解決方案

• 描述模式的組成元素(類與對象)、關係、職責及合作

• 解決方案是抽象的，不代表具體實現

• 結論

• 模式的利與弊

• 對系統的彈性、擴展性、可移植性的影響

設計模式的分類

• 以功能分

• 創建類 (Creational Patterns)

• 對類的實例化過程的抽象

• 結構類 (Structural Patterns)

• 將類或對象結合形成更大的結構

• 行為模式 (Behavioral Patterns)

• 對不同對象間劃分責任和算法的抽象化

• 以方式分

• 類模式

• 以繼承方式實現模式、靜態的

• 對象模式

• 以組合的方式實現模式、動態的

設計模式

簡單工廠模式

• 如何創建一個對象





• 優點

• Client 不再依賴 Sorter 的具體實現 (如 BubbleSorter)

• Client 符合 OCP

• 增加 Sorter 不影響 Client

• 缺點

• SorterFactory 不符合 OCP

• 增加 Sorter 需要修改 Factory

Singleton

• 在系統中，對於某類保證產生單一實例

• 性能需求面

• 減少實例頻繁創建和銷毀的資源消耗

• 功能需求面

• 使用各個實例時，便於進行統一控制

• 比如系統僅有一個打印機，故僅需一個打印機對象



• 整理

• 建構函式一定為私有訪問權限

• 外部無法用 new 來產生實例

• 將實例存於 private static 的成員變量中

• private: 外部無法取得

• static: 不用產生實例就可以賦值

• 類的實例僅能由 getInstance() 方法獲得

• 保證只有一個實例

• 此函式為 public static

• public : 客戶端可以呼叫

• static: 不用產生實例就可以呼叫此函式

• 做法 2 中的 getInstance() 一定要加 synchronized

• 避免多線程產生多重實例

• 單例是多線程重用的，所以必須設計為無狀態對象

• 只提供服務，不保存狀態

• 盡量使用做法 1 構造單實例

• 減少多線程進入 synchronized的開銷

Adapter

• 系統需要使用現有的類，但這個類的接口與系統所需要的不同

• 類的配適器

• 透過多重繼承轉換被適配類的接口

• 由被適配父類提供真正的功能



• 對象的適配器

• 透過組合轉換被適配類的接口

• 由被適配物件提供真正功能



• 適配器的應用

• JDBC Driver

• 對具體數據庫的適配器

• 如將 Oracle 適配到 JDBC 中

• JDBC-ODBC Bridge

• 將 Windows ODBC 適配到 JDBC 接口中

Template Method

• 擴展功能最基本的模式

• 是 "類" 的行為模式

• 透過 "繼承" 來實現擴展

• 基類負責算法的輪廓和骨架

• 子類負責算法的具體實現



• 形式

• 抽象方法

• protected abstract void step1()

• 強制子類實現該步驟

• 具體方法

• protected void doSomething()

• 子類可以覆蓋(override)此步驟，或利用父類的實作

• 若須明確告知子類不要覆蓋，則標明 final

• 鉤子方法

• protected void setUp()

• 父類有空的實現 (缺省適配器模式)

• 子類可以選擇性覆蓋，以便在特定的時機做事

Strategy

• 擴展功能最基本的模式

• 是 "對象" 的行為模式

• 透過 "組合" 的方式來實現擴展



• 使用時機

• 系統需要在多種算法中選擇一種時

• 系統重構時，針對條件語句 (if else/ switch case) 轉換成對於策略的多態性調用

• 對比模板方法的優點

• 使用策略的程序與策略的具體實現分開

• 策略對象可以自由組合

• 可能存在的問題

• 策略模式僅封裝 "算法的具體實現"，方便替換算法，但不關心何時使用何種算法，必須由客戶端來決定

Composite

• 是一種 "對象" 的結構模式

• 透過實作相同接口，達成組合的目的

• 會產生一個樹狀結構



Decorator

• 是一種 "對象" 的結構模式

• 也被稱為 "包裝器" (Wrapper)

• 適配器也稱作包裝器，但與裝飾器不同

• 適配器主要是轉換接口

• 裝飾器保持接口不變

• 形成一個 "鍊" 的結構



• 作用

• 不改變對客戶接口

• 擴展現有對象的功能

• 比較

• 與模板方法、策略模式比較

• 裝飾器保持對象功能不變，擴展其外圍功能

• 模板方法與策略模式則保持算法框架不變，擴展其內部的實現

• 與繼承比較

• 都可以用來擴展對象功能

• 裝飾器是動態的、繼承是靜態的

• 裝飾器可以任意組合

• 但須避免複雜化，或組合出預期之外的結果

依賴注入 (Dependecy Injection) & 控制反轉 IOC (Inversion of Control)

• IOC

• 反轉生成控制權給第三方 IOC 容器

• 由 IOC 產生 "被依賴對象"，並將其注入 "被注入對象"

• 降低兩者之間的耦合性，只讓雙方依賴第三方容器

• DI

• 將 "被依賴對象" 注入 "被動接收物件" 中