設計模式的五大原則

標籤：

1、單一職責

　　不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義：我們把職責定義為系統變化的原因。所有在定 義類，介面，方法的時候。定義完以後再去想一想是不能多於一個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於一個職 責。故違背單一職責，遇到這種情況應該重新細分職責，直到不會出現多種職責的類，介面方法為止（發現職責，並把那些職責相互分離）。單一職責的為最簡單的 五種原則之一。在軟體設計的過程中處處體現。無處不在。

2、開閉原則

　　開閉原則是指類、模組、方法是可以擴充的，但不可以 修改。開即對擴張開放，閉即對修改關閉。開閉原則的應用體現在，開發人員應該僅僅對程式中頻繁出現變化的地方進行抽象（封裝變化點）。對變化點的封裝即對 變化的修改關閉。對於變化的不確定性，可隨時擴充。即 繼承的使用。抽象類別的運用。

3、替換原則(Is-A)

　　替換原則即是總是保證子類可以替換它的基類。

　 　替換原則的實現。對於一組具有類似屬性，方法，變數的類。我們可以提取公用屬性，方法，變數做為一個基類（抽象類別或者類），使這一組類繼承基類，重寫虛 方法。現在這些繼承的類和基類的關係符合Is-A。如基類為鳥，則繼承類可以為麻雀，燕子。我們可以說麻雀Is-A鳥，燕子Is-A鳥。

　　在項目中所有使用子類的地方都可用父類替換，但在調用方法的時候 ，即呈現物件導向編程的多態性。即替換原則，非常重要的原則，也是比較對難的原則。

4、依賴倒置原則

　　a、高層模組不應該依賴於低層模組。二者都應該依賴於抽象
　　b、抽象不應該依賴於細節。細節應該依賴於抽象。

      在面向過程的開發語言中分析和設計，總是建立一些高層模組去調用低層模組、策略依賴於細節的軟體結構。實際上這種方法的目的就是要定義子程式階層，該 結構 描述了高層模組怎樣調用低層模組。而設計良好的物件導向的程式，正好“倒置”了這種依賴關係。高層模組不再依賴於低層模組，從而低層模組的修改不會影響到 高層模組，並且高層模組也是能非常容易的被重用，高層模組和低層模組都影響都依賴於抽象。這樣也非常符合強內聚松耦合的編程思想。故該原則也是架構設計的 核心原則。
      使用傳統的過程化程式設計所建立出來的依賴關係結構，策略是依賴於細節的，這是糟糕的，因為這樣會使策略受到細節改變的影響，物件導向的程式設計倒置了依賴關係結構，全程細節和策略都依賴抽象，並且常常是客戶程式擁有服務介面。
      事實上，這種依賴關係的倒置正是好的物件導向設計 的標誌所在，使用何種語言來編寫程式是無關緊要的。如果程式的依賴關係是倒置的，它就是物件導向的設計。如果程式的依賴關係不是倒置的，它就是過程化的設計。
      依賴倒置原則是實現許多物件導向技術所宣稱的好處的基本低層機制。它的正確應用對於建立可重用的架構來說是必需的。同時它對於構建在變化面前富有彈性的代碼也是非常重要的，由於抽象和細節彼此隔離，所以代碼也非常容易維護。

 

5、介面隔離原則

        應該說該原則是處理現有“胖”介面所存在的缺點。如果類的介面不是內聚的，就表示該類具有“胖”介面。換句話說“胖”介面可以分解成多組方法。每一組方法 都服務於一組不同的客戶程式。這樣，量引客戶程式可以使用一群組成員函數，而其他客戶程式可以使用其他組的成員函數。

        介面隔離的方法有兩種（分享客戶就是分離介面）：

               1、使用委託（此委託非.net委託[delegate]）分離介面

　　　　　　　使用委託即，建立一個委託類，用此類去實現分離後的其它介面中的方法。

               2、使用多重繼承分離介面、

　　　　　　　　此方法，即將現有“胖”介面分成供不同客戶程式調用的兩個或多個介面，而需要實現多個介面的客戶程式，則使用多重繼承來實現。

　 　　這兩種方法是實現介面隔離的全部方法，其中第二種方法使用較普遍，也比較簡單。而第一種方法使用起來相對比較複雜，而且在使用委託的過程中也會產生重 複的對象，則佔用已耗用時間和記憶體開銷。有的時候第二種方法是必須的，第一種方法是不能使用的。如：利用委派物件所做的轉換是必需的，或者不同的時候會需要 不同的轉換。

設計模式的五大原則