Frank Buschmann

Applying Patterns
 

上一頁 下一頁


Stable Design Center(穩定的設計核心)

Context:我們正以逐步細緻化的方式定義一個給定的次系統或大型元件。

Problem:

如何確保我們的結構一方面是穩定,且連貫一致的;另一方面卻仍允許修改及演進。有三股力量與這個問題有關。

  1. 若子系統或元件愈不能被修改,則他們在系統的生命週期中,就愈得以保持穩定與連貫一致。然而,我們至少要能支援系統的演進。

  2. 若設計結構愈被開放修改,則系統愈能適應客戶的特殊要求。然而,從另一方面來說;可修改性卻可能破壞軟體架構的一貫性。

  3. 子系統或大型元件的基礎構面不應該被改變。它們的結構及行為的完整性,在系統的生命週期中應該保持一致,否則我們可能危及它們的一般操作性。

Solution:

 

為系統重要的構面建立穩定的設計核心:每一版本中都需要的核心服務,以及牽涉許多服務執行的結構。例如基礎的領域模式,或是系統的通信基礎架構等。

擷取設計結構中的關鍵構面;亦即不能改變的本質部分:例如它的一般性責任、客戶端介面、使用此介面的通訊協定,以及其基本的分解結構,與內在元件如何合作的準則。所考慮的這個設計核心必須符合系統的各式背景;這個背景是以所擷取的構面為主的。

將此設計核心中為符合客戶要求,即有可能在跨越整個系統生命週期裡被修改或調適的部分準備好,以利後續的演進。對此,應盡可能地使用適當的設計樣式。例如要支援過濾現有的行為、或附加新的行為,我們可以使用 Decorator 樣式[GHJV95]。或者調整一個一般性行為成為特殊行為,我們可以使用 Template Method 樣式及 Strategy 樣式[GHJV95]

讓設計核心提供掛勾的功能,可以允許我們將來附加目前還無法預測的功能,有許多樣式可以幫忙,如 Visitor 樣式[GHJV95] Facet 樣式[PLoP96]

要避免用戶端與設計核心內部結構間,有直接的相依性。例如 Façade 樣式[GHJV95]可以提供對核心服務的存取定義而無須揭露其內部結構。Abstract Factory 樣式及 Builder樣式[GHJV95]可以讓用戶端 ,免於瞭解如何構建設計核心實體的詳細內容。

由此,從用戶端的觀點來看,我們獲得在系統生命週期中都很穩定的設計核心。它定義了明確的邊界與責任,也明確地定義了該如何地去使用它。系統中有賴於此設計核心的部分,將可以倚靠它的穩定性。

縱使如此,設計核心仍然允許持續發展。核心內部的細節,可以調適以符合特殊要求,而無須改變核心的關鍵元件或系統的其他部分。後續的擴充,也只需些微修改局部現有的部分,來附加功能。

如果我們必須改變設計核心中,一個用戶端可見的構面-縱使最小化這個需求,我們仍然無法完全從系統生命週期中將此排除-這個修改將會是非常昂貴的。因為這種改變將會影響到系統中相關於這個構面的所有部分。這是構建穩定設計核心的主要不利因素。

 

Example:

Broker 樣式[BMRSS96]定義了一個穩定的設計中心,它提供了在分散系統中元件溝通及合作的基礎建設。在 Broker 架構下其內部的構面,可能會因實作的不同而有所不同。但它的基本結構及用戶端介面,卻是固定的,甚至是標準化的。如此即可允許用戶端、伺服端元件甚至是不同的 Broker 實作間,透過在系統生命週期中保持穩定的使用通訊協定,而彼此間共同合作。


上一頁 下一頁