第14章設計樣式與框架

14‐1 設計樣式與框架的基礎

14‐2 GRASP樣式

14‐3 Gang of Four設計樣式

14‐4 使用設計樣式

14‐1 設計樣式與框架的基礎

14‐1‐1 設計樣式與框架

14‐1‐2 設計樣式的描述

14‐1‐1 設計樣式與框架‐說明

設計樣式與框架都可以幫助我們改進軟體品質和減少軟體系統的開發時間，其簡單說明如下所示：

• 設計樣式（Design Patterns）：對於一些重複發生的程式問題提供已證明可用的解決方案，它是可重複使用的一些成功的軟體架構和物件設計，基本上，我們並沒有發明設計樣式，而是在眾多前輩的成品中找出可重複使用的設計樣式。

• 框架（Framework）：一組類別集合可以提供特定類型軟體的一組服務，支援可重複使用的詳細設計和程式碼，它就是一個應用程式的準軟體，提供特定類型軟體的功能，我們只需繼承和使用框架的元件，就可以快速建立特定類型的完整軟體系統。

14‐1‐1 設計樣式與框架 ‐差異

設計樣式與框架的主要差異，如下所示：

• 設計樣式比框架更抽象化。

• 設計樣式比起框架來說，它是一種更小的架構元素。

• 設計樣式比框架擁有更高的適用性，因為設計樣式並沒有針對特定類型的軟體系統。

14‐1‐2 設計樣式的描述 ‐說明

設計樣式的描述（Design Pattern Description）可以幫助軟體系統開發者找到可使用在系統上，解決程式問題的樣式。

我們有多種方式來描述設計樣式，不過，設計樣式的描述通常與程式語言的種類和實作細節無關。

14‐1‐2 設計樣式的描述 ‐內容1

樣式名稱（Pattern Name）：描述樣式的名稱，這個名稱可以代表此樣式的精髓和本質。

大綱（Synopsis）：描述樣式目的、意圖和其針對的特殊設計問題。

描述（Description）：描述樣式參與的物件、一般的物件架構和在物件之間是如何進行通訊。

強制條件（Forces）：說明使用此樣式的任何可能限制條件，例如：對於某些使用樣式的問題，可能需要在分散式架構的電腦上執行。

14‐1‐2 設計樣式的描述 ‐內容2

實作（Implementation）：描述樣式針對特定情況的可能實作。

後果（Consequences）：描述使用此樣式可能的後果和影響。

相關樣式（Related Patterns）：有哪些樣式是修改或擴充此樣式，或可以與哪些樣式合作來建立出更複雜的案例。

14‐2 GRASP樣式

14‐2‐1 資訊專家樣式

14‐2‐2 建立者樣式

14‐2‐3 控制者樣式

14‐2‐4 高內聚力樣式

14‐2‐5 低耦合度樣式

14‐2 GRASP樣式

GRASP是 Craig Larman在其著作「Applying UML and Patterns」提出的樣式，Larman宣稱GRASP是基本物件設計的一種方法，其主要目的是用來指定類別責任，可以幫助我們建立良好的設計類別。

GRASP樣式有很多種，在本節準備說明常用的：資訊專家（Information Expert）、建立者（Creator）、控制者（Controller）、高內聚力（High Cohesion）和低耦合度（Low Coupling）樣式。

14‐2‐1 資訊專家樣式 ‐說明

資訊專家樣式（Information Expert Pattern）是用來解決如何決定哪一個物件負責執行特殊的行為，可以幫助我們決定和了解哪一個類別有責任執行此行為。

專家樣式的原則為：「將責任指定給資訊專家，即擁有資訊的哪一個類別，必須完成責任。」

14‐2‐1 資訊專家樣式 ‐範例(問題)

例如：訂購商品的UML類別圖包含：訂單、訂單明細和商品共三個類別，如下圖所示：

14‐2‐1 資訊專家樣式 ‐範例(指派行為)

現在，我們準備建立某一使用案例的通訊圖來提供使用者訂單的總價，並且使用資訊專家樣式來指派類別的行為，如下表所示：

需要指派的行為 擁有資訊的類別 指派類別

計算訂單總價 訂單 訂單

計算商品小計（商品價格X數量）

訂單明細 訂單明細

提供商品價格 商品 商品

14‐2‐1 資訊專家樣式 ‐範例(指定行為的類別圖)

在依上表使用資訊專家樣式後，可以建立指定行為的類別圖，如下圖所示：

14‐2‐2 建立者樣式 ‐說明

建立者樣式（Creator Pattern）是在決定誰負責建立特定類別的實例，當類別A有責任建立類別B的實例時，物件A就是物件B的建立者，若：

• 物件A包含物件B。• 物件A緊密使用物件B。• 物件A擁有初始資料需要傳遞給物件B。

14‐2‐2 建立者樣式 ‐範例(問題)

例如：在訂單新增訂單項目時，訂單類別圖中的哪一個物件負責建立訂單明細物件，如下圖所示：

14‐2‐2 建立者樣式 ‐範例(找出建立者)

因為訂單包含訂單明細，所以訂單物件需要建立訂單明細物件；訂單物件是訂單明細物件的建立者，如下圖所示：

14‐2‐3 控制者樣式 ‐說明

控制者樣式（Controller Pattern）是決定哪一個非使用介面類別（Non‐UI Class）負責處理系統事件，其觀念類似Ivar Jacobson的控制類別。

雖然在軟體系統中會有很多物件都可以接收系統事件，但並不表示它們都需要處理此事件，Larman建議這些事件應該由符合下列條件的類別來處理，如下所示：

• 類別代表整個系統、裝置或子系統，稱為Facade控制者。

• 在系統事件產生時，代表使用案例情節的類別，它是位在動作者和商業類別之間的類別，稱為使用案例控制者（Use Case Controller），其名稱通常是在使用案例名稱之後加上控制、管理或操作。

14‐2‐3 控制者樣式 ‐範例

例如：在上一節新增訂單項目的循序圖，新增【訂單項目控制】物件來面對介面層，它就是一個控制者，如下圖所示：

14‐2‐4 高內聚力樣式 ‐說明

對於良好的物件導向設計來說，每一個類別不應該做太多事，換句話說，良好設計類別的特徵，就是每一個類別只會有少量的方法。

高內聚力樣式（High Cohesion Pattern）就是在建立類別時，每一個類別都是一種關鍵抽象化（Key Abstraction），也就是說，它只能代表真實世界中的一個東西，保證每一個類別的責任都是專注的，即高內聚力。

14‐2‐4 高內聚力樣式 ‐範例(沒有內聚力)

例如：電梯系統的【電梯控制】類別，如右圖所示：

14‐2‐4 高內聚力樣式 ‐範例(高內聚力) 高內聚力樣式就是在建立關鍵抽象化的類別，我們可以將

【電梯控制】類別分割成四個類別，如下圖所示：

14‐2‐5 低耦合度樣式 ‐說明

低耦合度樣式（Low Coupling Pattern）就是保持類別之間最低的耦合度，因為低耦合度是良好設計類別的關鍵。

當一個類別是高耦合度，表示類別需要依賴其他很多個類別，也就是和很多個類別之間有各種類別關係，此時，我們可以使用封裝（Encapsulation）來降低耦合度。

14‐2‐5 低耦合度樣式 ‐範例(增加耦合度)例如：在訂購商品系統中，客戶類別擁有訂單類別，我們讓客戶類別來建立訂單明細類別，其通訊圖如下圖所示：

14‐2‐5 低耦合度樣式 ‐範例(降低耦合度) 如果讓訂單類別來建立訂單明細類別，這種方式可以降低

類別之間的耦合度，其好處是當實作需要更改訂單明細類別時，只會影響到訂單類別，而不會影響到客戶類別，其通訊圖如下圖所示：

14‐3 Gang of Four 設計樣式

14‐3‐1 設計樣式的種類

14‐3‐2 使用設計樣式

14‐3‐1 設計樣式的種類

設計樣式是由 Christopher Alexander 的著作所啟發，但是真正介紹到軟體世界，則是由 Erich Gamma、Richard Helm、Relph Johnson 和 John Vlissides（稱為Gang of Four）四位設計樣式大師所著「Design Patterns：Elements of Reuseable Object‐Oriented Software」一書。

從此之後，有無數書籍和文章探討設計樣式，設計樣式逐漸成為物件導向軟體工程（Object‐Oriented Software Engineering）的必備知識。在Gang of Four書中介紹23種設計樣式，可以分成三類：

• 建構樣式（Creational Patterns）• 結構樣式（Strutural Patterns）• 行為樣式（Behavioral Patterns）

14‐3‐2 使用設計樣式

設計樣式是經過嚴格測試和驗證能夠有效解決指定程式問題的一組物件集合，和之間的架構。軟體系統開發者在解決程式問題時，如果發現某種設計樣式可以使用，就可以馬上套用設計樣式來快速建立經測試且可靠的物件架構。

設計樣式的使用可以分為兩大基本步驟：

• 步驟一：選擇設計樣式

• 步驟二：使用設計樣式

14‐4 使用設計樣式

14‐4‐1 Factory Method樣式

14‐4‐2 Abstract Factory樣式

14‐4‐3 Facade樣式

14‐4‐4 State樣式

14‐4‐5 Strategy樣式

14‐4‐6 Flyweight樣式

14‐4‐7 Singleton樣式

14‐4‐1 Factory Method 樣式 ‐說明

Factory Method樣式屬於一種建構樣式，它是模擬工廠生產產品的樣式，生產的產品是一個一個物件。Factory Method樣式是定義一個介面來建立物件，但是讓繼承的子類別來決定建立哪一種類別的物件，如下圖所示：

14‐4‐1 Factory Method 樣式 ‐範例

例如：在飲料工廠生產茶飲料，統一公司生產茶裏王；味全公司生產絕品好茶，如下圖所示：

14‐4‐2 Abstract Factory 樣式 ‐說明

Abstract Factory樣式也屬於一種建構樣式，它是提供一個介面來建立屬於同一個家族的物件，而不用指明它們的實體物件，如下圖所示：

14‐4‐2 Abstract Factory樣式 ‐說明 例如：乳製品工廠光泉公司擁有兩條生產線可以生產保久

乳和優酪乳，如下圖所示：

14‐4‐3 Façade 樣式 ‐說明

Facade樣式屬於一種結構樣式，它提供一組統一介面的物件來作為子系統的對外介面，例如：類別函數庫。事實上，Facade樣式是定義一組高階介面來讓子系統更容易使用，換個角度來說，它就是使用一組簡單的介面來包裝複雜的子系統。

14‐4‐3 Façade 樣式 ‐圖例

14‐4‐4 State 樣式 ‐說明

State樣式屬於一種行為樣式，允許物件因內部的狀態改變而改變其行為。State樣式可以將每一個狀態建立成物件，讓它們自行負責狀態切換的行為，如下圖所示：

14‐4‐4 State 樣式 ‐範例

例如：一輛車在加速時可以切換至一檔、二檔或三檔，不同檔的速度上限不同，換句話說，同樣是加速，但有不同的實作，我們可以使用State樣式來完成車輛加速的狀態轉換，如下圖所示：

14‐4‐5 Strategy 樣式 ‐說明

Strategy樣式也是一種行為樣式，可以定義一組相關演算法，在封裝成不同類別後，讓使用者獨立使用這些演算法。換句話說，Strategy 樣式著重於封裝一組相關的演算法；State樣式則是不同狀態之間的轉換邏輯，如下圖所示：

14‐4‐5 Strategy 樣式 ‐範例

例如：車輛的定期保養分為五千公里的小保養和一萬公里的大保養，定期保養一定都會更換機油，但是大小保養進行電腦診斷的項目不同，因為小保養和大保養是兩種不同的策略，所以可以使用Strategy樣式執行車輛的定期保養，如下圖所示：

14‐4‐6 Flyweight 樣式 ‐說明

Flyweight樣式是一種結構樣式，可以共用同一個類別的物件，以避免建立大量相同內容的物件，不只花費大量的記憶體空間，更會降低執行效率。換句話說，Flyweight樣式是一種提高程式效率和性能的結構樣式，如下圖所示：

14‐4‐6 Flyweight 樣式 ‐範例

例如：在文字處理軟體（Word）是使用圖形顯示每一個文字的字型、尺寸和色彩，如果每一個文字都是一個物件，成千上萬的物件將花費龐大的記憶體空間，Flyweight樣式讓每一個文字參考到封裝的共用類別：樣式介面（即Word的樣式），換句話說，我們只需少量實作樣式介面的物件，就可以編排出整篇漂亮的文件。

14‐4‐7 Singleton 樣式 ‐說明

Singleton樣式是一種建構樣式，保證類別只擁有一個存在的實例，可以提供全域指標來存取此實例，如下圖所示：

14‐4‐7 Singleton 樣式 ‐實作

Java語言實作Singletion樣式的程式碼，如下所示：public class Singleton {private static final Singleton INSTANCE = new Singleton();// Private建構子

private Singleton() {}public static Singleton getInstance() {return INSTANCE;

}}