設計模式的五大原則

一、單一職責

　　不管是在設計類，接口仍是方法，單一職責都會到處體現，單一職責的定義：咱們把職責定義爲系統變化的緣由。全部在定 義類，接口，方法的時候。定義完之後再去想想是不能多於一個的動機去改變這個類，接口，方法。若是答案是確定的，說明定義的類，接口，方法則多於一個職 責。故違背單一職責，遇到這種狀況應該從新細分職責，直到不會出現多種職責的類，接口方法爲止（發現職責，並把那些職責相互分離）。單一職責的爲最簡單的 五種原則之一。在軟件設計的過程當中到處體現。無處不在。

二、開閉原則

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

三、替換原則(Is-A)

　　替換原則便是老是保證子類能夠替換它的基類。

　 　替換原則的實現。對於一組具備相似屬性，方法，變量的類。咱們能夠提取公共屬性，方法，變量作爲一個基類（抽象類或者類），使這一組類繼承基類，重寫虛 方法。如今這些繼承的類和基類的關係符合Is-A。如基類爲鳥，則繼承類能夠爲麻雀，燕子。咱們能夠說麻雀Is-A鳥，燕子Is-A鳥。

　　在項目中全部使用子類的地方均可用父類替換，但在調用方法的時候 ，即呈現面向對象編程的多態性。即替換原則，很是重要的原則，也是比較對難的原則。

四、依賴倒置原則

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

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

五、接口隔離原則

應該說該原則是處理現有「胖」接口所存在的缺點。若是類的接口不是內聚的，就表示該類具備「胖」接口。換句話說「胖」接口能夠分解成多組方法。每一組方法 都服務於一組不一樣的客戶程序。這樣，量引客戶程序可使用一組成員函數，而其餘客戶程序可使用其餘組的成員函數。

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

一、使用委託（此委託非.net委託[delegate]）分離接口

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

二、使用多重繼承分離接口、

　　　　　　　　此方法，即將現有「胖」接口分紅供不一樣客戶程序調用的兩個或多個接口，而須要實現多個接口的客戶程序，則使用多重繼承來實現。

　 　　這兩種方法是實現接口隔離的所有方法，其中第二種方法使用較廣泛，也比較簡單。而第一種方法使用起來相對比較複雜，並且在使用委託的過程當中也會產生重 復的對象，則佔用運行時間和內存開銷。有的時候第二種方法是必須的，第一種方法是不能使用的。如：利用委託對象所作的轉換是必需的，或者不一樣的時候會須要 不一樣的轉換。