Frank Buschmann

Applying Patterns
 

上一頁 下一頁


Repair Instead Large Lump Design(以修補替代大堆頭式的設計)

Context:我們正以逐個成長的方式發展一個軟體系統。

Problem :

在後續的設計過程中,如果發生某些設計問題,而其解決方案會影響系統現有的架構時,我們該如何地處理?例如,當客戶要求‘立即增加某項功能’所產生的問題。或是當我們要使用的預鑄元件與現有設計無法整合時。要解決這些衝突即意味著要平衡兩股力量。

 

Solution:

修補現有的架構 [Gab96]。不要因為不恰當的大結構與整體設計準則,而限制了使用最佳化的方式,來解決將手邊的設計問題。


 

找出該設計問題的解決方案中,所有會影響現有軟體架構的面向:特別是會影響包含此解決方案的上層結構的面向。依據已確認的面向,調整這個部分的設計。同樣的;修正該結構中所有會受到這個調整所影響 之個別元件的規格,我們可能需要先將這些修改做好以後,再將設計問題的解決方案嵌入這個修正過後的結構中。

換言之,我們再次以逐步細緻化的方式來解決這些設計問題;這可以引導不合適的結構 ,去整合手上設計問題的解決方案。然而,這次我們並不僅是只考慮系統整體的需求,及它們本身較大的問題,同時也考慮我們目前所面臨低階設計問題的需求。

當調整一個既定的結構時,如果可能的話,盡量避免違反設計準則。除此以外,遞迴地修改所有會受到影響的結構,如果有需要,甚至向上提升至架構願景的修改。

因此,構建出來的軟體架構不會是大堆頭式設計的結果:把架構中的每一部份都固定起來,即只要完成某一部份的規格後,便一直保持不變。這個架構會持續地改變及成長,並且所有細部的各層還都能保持連貫一致。因此這個修改的觀點是一個逐個成長程序重要的準則。

Example:


假設;我們想要將服務的請求從控制服務執行的細節中分離出來,一開始,我們先應用Command樣式[GHJV95]將請求封裝成物件。而應用系統的使用端介面元件;像選單及對話框則透過Command物件的Execution來啟動指令的執行。

 

就在這個結構被確認後,一個新的需求產生了:暫停及重新執行一個指令的功能。上述的設計方式無法達成這個要求。因為我們必須能在任何的時間點上存取所有正在執行中的指令。但是,關於哪些指令正在執行中的知識 ,卻是分散在眾多的呼叫者上,而非集中在單一的一個元件中。

Command Processor樣式[BMRSS96]提供了我們需要的結構,因此我們修改現有的設計,加入一個指令處理器(command processor),並重組了呼叫者與 Command 物件間的關係。呼叫者仍然構建Command 物件,但不啟動它們的執行,而是將它們傳遞給指令處理器,指令處理器維護接收到的指令,啟動並控制它們的執行。因此,暫停及重新執行指令的功能,便能有效的被實作[BMRSS96].


 


上一頁 下一頁