設計模式後的設計理念：需求變化，針對介面編程，優先使用彙總

標籤：設計模式下面的原則和理念   繼承和彙總   介面編程   需求變化   

模式的基本元素：模式的名稱，該模式所能解決的問題（模式應用的情境），解決方案，使用該模式後的結果（包括優點和缺點）模式的分類：

架構模式：架構模式描述了軟體系統基本的結構組織策略，實際上就是關於軟體的宏觀組織的規則和指南

設計模式：設計模式描述的是在軟體系統的某一局部不斷重現的核心解決方案，這種解決方案以完善的設計結構出現，可以被應用到以後出現的類似的語境中

通用職責分配軟體模式（GRASP模式）：描述了在物件導向設計過程中把職責分配給系統中不同對象的有效經驗和基本原則，GRASP模式只是對職責分配過程中的設計原則的總結和概括，而沒有為每一個模式提供建議的具體機構

蘊含在設計模式中的設計原則和理念：

• 設計模式最根本的意圖是適應需求變化：易變性根本就是軟體的一個內在的特徵；設計模式最大的用途就是適應需求變化，在設計模式的協助下，我們可以在設計階段就為未來可能發生的變化留下足夠的空間（具體見下面機器人餵豬的案例）；只實現你需要的東西，並在這一原則的指導下適度使用設計模式，應該把設計模式的應用範圍限制在系統中那些明顯不穩定，極有可能變化的部分
• 針對介面編程，而不是針對實現編程：針對介面編程的組件不需要知道對象的具體類型和實現，只需要知道抽象類別定義了那些介面，這減少了實現上的依賴關係
• 優先使用彙總而不是繼承

機器人餵豬案例：

一開始養豬場打算用機器人來喂大白豬：

需求變化一：後來引進了長白豬：

現在的問題就是養豬場的需求不斷變化的問題，加入有引進了其他種類的豬或者其他的物種，需要不斷修改代碼；這是就應該添加一個豬的抽象介面，並且修改豬機器人的代碼，使其不考慮豬的類型，只應用抽象的豬的介面來操作所有豬的對象執行個體

需求變化二：讓機器人來打掃豬舍（這可能隱藏了更多的變化的需求，未來機器人的功能還可能不斷增加，）

更改一：

但是這裡存在一個問題：圖中的繼承結構是在編譯器件就確定了的，在運行期不能發生任何變化，因此，如果養豬場需要一個餵豬機器人和一個清潔機器人，那麼必須在養豬場放進這兩個具體的機器人，以此類推，如果未來養豬場還需要其他種類機器人時，對象數目很大，而且沒添加一種機器人就必須修改代碼中的某一個地方，

更改二：

繼承和彙總的比較：

• 繼承反映的是類之間的“‘.......是一個.......”這樣的關係，它在編譯期間靜態定義，繼承的優點是使用起來比較簡單，但是缺點是：不能再運行期間改變繼承的結構，基類中往往定義了部分的實現，基類的實現暴露給衍生類別後，繼承機制就會破壞資料和操作的封裝，使衍生類別對基類產生的較強的依賴（相對於彙總而言，該使用還是要使用的）
• 彙總反映的是類之間“.................有一個.....”的關係，是在運行期間動態定義的，因此被彙總對象的類型可以很容易地在運行期間發生變化，只要保證他們的介面相同，滿足完全替換原則即可，而且使用彙總可以更好地封裝對象， 使每一個類集中在單個職能上，類的繼承層次也會保持較小的規模；缺點是他不是物件導向語言直接支援的一個特性，使用者必須編寫一些代碼來完成彙總功能
• 在不違反繼承和彙總所反映的關係的前提下，應該優先使用彙總而不是繼承，同時，彙總也必須和介面及相關的繼承結構協同使用

設計模式後的設計理念：需求變化，針對介面編程，優先使用彙總