C++——設計模式說明

時間 2019-11-07

標籤 c++ 設計模式說明欄目 C&C++ 简体版

原文原文鏈接

1、設計模式6大原則

名稱解釋
0、單一職責原則（SRP）
就一個類而言，應該僅有一個引發它變化的緣由。
1、"開放－封閉"原則(OCP)
在軟件設計模式中，這種不能修改，但能夠擴展的思想也是最重要的一種設計原則。即軟件實體（類、模板、函數等等）應該能夠擴展，可是不可修改。
【通俗】：設計的時候，時刻考慮，儘可能讓這個類是足夠好，寫好了就不要去修改了，若是新需求來，咱們增長一些類就完事了，原來的代碼能不動則不動。
2、里氏代換原則（LSP）
1.一個軟件實體若是使用的是一個父類的話，那麼必定適用於該子類，並且他覺察不出父類對象和子類對象的區別。也就是說，在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化。
【一句話】：子類型必須可以替換掉他們的父類型。
3、依賴倒置原則(DIP)
1.高層模塊不該該依賴於底層模塊。兩個都應該依賴抽象。2.抽象不該該依賴於細節，細節依賴於抽象（
【白話】：針對接口編程，不要針對實現編程。
4、接口隔離原則（ISP）
1.使用多個專門的接口比使用單一的總接口總要好。換而言之，從一個客戶類的角度來說：一個類對另一個類的依賴性應當是創建在最小接口上的。
2．過於臃腫的接口是對接口的污染。不該該強迫客戶依賴於它們不用的方法。
5、合成/聚合複用原則（CARP）
儘可能使用合成/聚合，儘可能不要使用類繼承。
【聚合】：表示一種弱的擁有關係，體現的是A對象能夠包含B對象，但B對象不是A對象的一部分。
【合成】：一種強的擁有關係，提現了嚴格的部分和總體的關係，部分和總體的生存週期一致。
6、迪米特法則（LoD）
最少知識原則強調類之間的鬆耦合。即：若是兩個類沒必要彼此直接通訊，那麼着兩個類就不該當發送直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。java

___大部份內容摘自《大話設計模式》
1.樓主？題目不是6個設計模式嗎？怎麼列舉了7個？
答：不一樣的書上列舉的不太同樣，單一模式原則和接口隔離原則多數都提了一個。本文都列舉上，待深刻探究後給出詳細分析。
2.接口隔離原則與單一職責原則不是相同的嗎？
答：錯，接口隔離原則與單一職責的審視角度是不相同的。
單一職責要求的是類和接口職責單一，注重的是職責，這是業務邏輯上的劃分；
而接口隔離原則要求接口的方法儘可能少。例如一個接口的職責可能包含10個方法，這10個方法都放在一個接口中，而且提供給多個模塊訪問，各個模塊按照規定的權限來訪問，在系統外經過文檔約束「不使用的方法不要訪問」，按照單一職責原則是容許的，按照接口隔離原則是不容許的，由於它要求「儘可能使用多個專門的接口」,專門的接口指什麼？就是指提供給每一個模塊都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是創建一個龐大的臃腫的接口，容納全部的客戶端訪問。程序員

2、23種設計模式：算法

定義/概念
1 簡單工廠模式
Simple Factory Pattern 從設計模式的類型上來講，簡單工廠模式是屬於建立型模式，又叫作靜態工廠方法（StaticFactory Method）模式，但不屬於23種GOF設計模式之一。簡單工廠模式是由一個工廠對象決定建立出哪種產品類的實例。簡單工廠模式是工廠模式家族中最簡單實用的模式，能夠理解爲是不一樣工廠模式的一個特殊實現。
2 策略模式
Strategy Pattern 策略模式(strategy)定義了一系列的算法，並將每個算法封裝起來，並且使它們還能夠相互替換。策略模式讓算法獨立於使用它的客戶而獨立變化。、
策略模式的組成:
1）抽象策略角色：策略類，一般由一個接口或者抽象類實現。
2）具體策略角色：包裝了相關的算法和行爲。
3）環境角色：持有一個策略類的引用，最終給客戶端調用。
3 裝飾模式
Decorator Pattern 動態的給一個對象添加一些額外的職責，就增長功能來講，裝飾模式比生成子類更爲靈活。
總結：把類中裝飾功能從類中搬移去除，這樣能夠簡化已有的類；最大好處：有效地把類的核心職責和裝飾功能分開了。並且能夠去除重複的裝飾邏輯。
4 代理模式
Proxy Pattern 爲其餘對象提供一個代理以控制這個對象的訪問。
在某些狀況下，一個對象不想或者不能直接引用另外一個對象，而代理對象能夠在客戶端和目標對象之間起到中介的做用
5. 工廠方法模式Fatory Method 定義一個用於建立對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。
【實現】工廠方法模式實現時，客戶端須要決定實例化哪個工廠來實現運算類，選擇判斷的問題仍是存在的，也就是說，工廠方法把簡單工廠的內部邏輯判斷轉移到了客戶端的代碼來進行，你想要加功能，原本改工廠類的，如今是修改客戶端。
6 原型模式Prototype Pattern 用原型實例指定建立對象的種類，而且經過拷貝這些原型建立新的對象。
【白話】原型對象其實就是從一個對象再建立另一個可定製的對象，並且不需知道任何建立的細節。
7 模板方法模式
Template Method 定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類不改變一個算法的結構便可重定義該算法的某些特定步驟。
【白話】：模板方法模式是經過把不變行爲搬移到超類，去除子類中的重複代碼來體現他的優點。
8 外觀模式
Facade Pattern 爲子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
9 建造者模式Builder Pattern 將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。
【注意：】首先它意圖是要構建一個複雜的對像，而這個複雜的對像每每須要由好幾個子對象或分步驟來完成最終的這個對象的構建，而這個複雜對象的子對像常常須要不斷的變化，但它的構建過程是相對是穩定的。
精髓：經過一個統一的工序或者約束構造出同一的對象。
10 觀察者模式
發佈-訂閱模式Publish-Subscribe Pattern 定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知全部觀察者對象，使它們可以夠自動更新本身。
11 抽象工廠模式Abstract Factory Pattern 提供一個建立一系列相關或相互依賴對象的接口，而無需指定他們具體的類。
【用途】：用於交換產品系列，如ACCESS->SQL SERVER；
產品的具體類名被具體工廠的實現分離。
12 狀態模式
State Pattern 當一個對象的內在狀態改變時容許改變其行爲，這個對象看起來像是改變了其類。
【主要解決】：對象狀態轉換的條件表達式過於複雜的狀況。把狀態的判斷邏輯轉移到表示不一樣狀態的一個類中，能夠把複雜的判斷邏輯簡化。
13 適配器模式Adapter Pattern 將一個類的接口轉換成客戶但願的另一個接口。Adapter模式使得原來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。
14 備忘錄模式Memento Pattern 在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就可將該對象恢復到原來保存的狀態。
15 組合模式Composite Pattern 將對象組合成樹形結構以表示‘部分-總體’的層次結構。組合模式使得用戶對單個對象和組合對象的使用具備一致性。
【使用時機】：當發現需求中是體現部分與總體層次的結構時，以及你但願用戶能夠忽略組合對象與單個對象的不一樣，統一地使用組合結構中的全部對象時，就應該考慮用組合模式。
16 單例模式singleton Pattern 保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
【解釋】：由於Singleton類封裝它的惟一實例，這樣它能夠嚴格地控制客戶怎麼訪問它以及什麼時候訪問它。簡單的說就是對惟一實例的受控訪問。
17 橋接模式
Bridge Pattern 將抽象部分與它的實現部分分離，使它們均可以獨立地變化。
【解釋】：實現系統可能有多角度分類，每一種分類都有可能變化，那麼就把這種多角度分離出來讓他們獨立變化，減小他們之間的耦合。
18 命令模式Command Pattern 將一個請求封裝成一個對象，從而使你可用不一樣的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可撤銷的操做。
19 職責鏈模式
Chain of Responsibility Pattern 使多個對象都有機會處理請求，從而避免請求的發送者和接受者之間的耦合關係。將這個對象連成一個鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。
【關鍵】:當客戶提交一個請求後，請求是沿着鏈傳遞直至有一個ConcreteHandler對象負責處理它。
20 中介者模式Mediator Pattern 用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯式的互相引用，從而使耦合鬆散，並且能夠獨立的改變他們之間的交互。
【應用場景】：一組對象已定義良好可是須要複雜的方式進行通訊的場合，以及想定製一個分佈在多個類中的行爲，而又不想生成太多的子類的場合。
21 享元模式FlyWeight Pattern 運用這種技術可有效地支持大量粒度的對象。
【使用場合】：能夠避免大量類似類的開銷。對於C++來講就是共用一個內存塊啦，對象指針指向同一個地方。
若是一個應用程序使用了大量的對象，而這些對象形成了很大的存儲開銷就應該考慮使用。
還有就是對象的大多數狀態能夠外部狀態，若是刪除對象的外部狀態，那麼能夠用較少的共享對象取代多組對象，此時能夠考慮使用享元。
22 解釋器模式Interpreter Pattern 給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。
【使用】：若是一個特定問題發生的頻率足夠高，那麼可能就值得將該問題的各個實例表述爲一個簡單語言中的句子。這樣就能夠構建一個解釋器，該解釋器經過解釋這些句子來解決該問題。
23 訪問者模式Visitor Pattern 表示一個做用於某對象結構中的各元素的操做，它使你能夠在不改變各元素的類的前提下定義做用於這些元素的新操做。
【優勢】：增長新的操做很容易，由於增長新的操做意味着增長一個新的訪問者。訪問者的模式將有關的行爲集中在一個訪問者對象中。
【缺點】：增長新的數據結構變得很困難。

___大部份內容摘自《大話設計模式》
我的感受：
1.可能剛開始看每一個設計模式的時候，經過實例能知道其應用原理？可是當多個模式一塊兒的時候，好比：適配器模式、橋接模式、中介者模式的區別？可能就不是很快的說清楚（固然也說明本身沒有完全領悟，另外一個方面說明了本身沒有用過相關的設計模式。
2.在實踐中若是應用了設計模式才能真正感知她的妙處，這也是我所欠缺的。編程

單一職責原則（Single Responsibility Principle）
定義：不要存在多於一個致使類變動的緣由。通俗的說，即一個類只負責一項職責。
問題由來：類T負責兩個不一樣的職責：職責P1，職責P2。當因爲職責P1需求發生改變而須要修改類T時，有可能會致使本來運行正常的職責P2功能發生故障。
解決方案：遵循單一職責原則。分別創建兩個類T一、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
說到單一職責原則，不少人都會不屑一顧。由於它太簡單了。稍有經驗的程序員即便歷來沒有讀過設計模式、歷來沒有據說過單一職責原則，在設計軟件時也會自覺的遵照這一重要原則，由於這是常識。在軟件編程中，誰也不但願由於修改了一個功能致使其餘的功能發生故障。而避免出現這一問題的方法即是遵循單一職責原則。雖然單一職責原則如此簡單，而且被認爲是常識，可是即使是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。爲何會出現這種現象呢？由於有職責擴散。所謂職責擴散，就是由於某種緣由，職責P被分化爲粒度更細的職責P1和P2。
好比：類T只負責一個職責P，這樣設計是符合單一職責原則的。後來因爲某種緣由，也許是需求變動了，也許是程序的設計者境界提升了，須要將職責P細分爲粒度更細的職責P1，P2，這時若是要使程序遵循單一職責原則，須要將類T也分解爲兩個類T1和T2，分別負責P一、P2兩個職責。可是在程序已經寫好的狀況下，這樣作簡直太費時間了。因此，簡單的修改類T，用它來負責兩個職責是一個比較不錯的選擇，雖然這樣作有悖於單一職責原則。
舉例說明，用一個類描述動物呼吸這個場景：
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空氣");
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
}
}
運行結果：
牛呼吸空氣
羊呼吸空氣
豬呼吸空氣

程序上線後，發現問題了，並非全部的動物都呼吸空氣的，好比魚就是呼吸水的。修改時若是遵循單一職責原則，須要將Animal類細分爲陸生動物類Terrestrial，水生動物Aquatic，代碼以下：
class Terrestrial{
public void breathe(String animal){
System.out.println(animal+"呼吸空氣");
}
}
class Aquatic{
public void breathe(String animal){
System.out.println(animal+"呼吸水");
}
}

public class Client{
public static void main(String[] args){
Terrestrial terrestrial = new Terrestrial();
terrestrial.breathe("牛");
terrestrial.breathe("羊");
terrestrial.breathe("豬");

Aquatic aquatic = new Aquatic();
aquatic.breathe("魚");
}
}
運行結果：
牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚呼吸水

咱們會發現若是這樣修改花銷是很大的，除了將原來的類分解以外，還須要修改客戶端。而直接修改類Animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，代碼以下：
class Animal{
public void breathe(String animal){
if("魚".equals(animal)){
System.out.println(animal+"呼吸水");
}else{
System.out.println(animal+"呼吸空氣");
}
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
animal.breathe("魚");
}
}
能夠看到，這種修改方式要簡單的多。可是卻存在着隱患：有一天須要將魚分爲呼吸淡水的魚和呼吸海水的魚，則又須要修改Animal類的breathe方法，而對原有代碼的修改會對調用「豬」「牛」「羊」等相關功能帶來風險，也許某一天你會發現程序運行的結果變爲「牛呼吸水」了。這種修改方式直接在代碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患倒是最大的。還有一種修改方式：
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空氣");
}

public void breathe2(String animal){
System.out.println(animal+"呼吸水");
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
animal.breathe2("魚");
}
}
能夠看到，這種修改方式沒有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責原則，但在方法級別上倒是符合單一職責原則的，由於它並無動原來方法的代碼。這三種方式各有優缺點，那麼在實際編程中，採用哪一中呢？其實這真的比較難說，須要根據實際狀況來肯定。個人原則是：只有邏輯足夠簡單，才能夠在代碼級別上違反單一職責原則；只有類中方法數量足夠少，才能夠在方法級別上違反單一職責原則；
例如本文所舉的這個例子，它太簡單了，它只有一個方法，因此，不管是在代碼級別上違反單一職責原則，仍是在方法級別上違反，都不會形成太大的影響。實際應用中的類都要複雜的多，一旦發生職責擴散而須要修改類時，除非這個類自己很是簡單，不然仍是遵循單一職責原則的好。
遵循單一職責原的優勢有：
能夠下降類的複雜度，一個類只負責一項職責，其邏輯確定要比負責多項職責簡單的多；
提升類的可讀性，提升系統的可維護性；
變動引發的風險下降，變動是必然的，若是單一職責原則遵照的好，當修改一個功能時，能夠顯著下降對其餘功能的影響。
須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都須要遵循這一重要原則。

里氏替換原則（Liskov Substitution Principle）
確定有很多人跟我剛看到這項原則的時候同樣，對這個原則的名字充滿疑惑。其實緣由就是這項原則最先是在1988年，由麻省理工學院的一位姓裏的女士（Barbara Liskov）提出來的。
定義1：若是對每個類型爲 T1的對象 o1，都有類型爲 T2 的對象o2，使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。
定義2：全部引用基類的地方必須能透明地使用其子類的對象。
問題由來：有一功能P1，由類A完成。現須要將功能P1進行擴展，擴展後的功能爲P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會致使原有功能P1發生故障。
解決方案：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，儘可能不要重寫父類A的方法，也儘可能不要重載父類A的方法。
繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），其實是在設定一系列的規範和契約，雖然它不強制要求全部的子類必須聽從這些契約，可是若是子類對這些非抽象方法任意修改，就會對整個繼承體系形成破壞。而里氏替換原則就是表達了這一層含義。
繼承做爲面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了弊端。好比使用繼承會給程序帶來侵入性，程序的可移植性下降，增長了對象間的耦合性，若是一個類被其餘的類所繼承，則當這個類須要修改時，必須考慮到全部的子類，而且父類修改後，全部涉及到子類的功能都有可能會產生故障。
舉例說明繼承的風險，咱們須要完成一個兩數相減的功能，由類A來負責。
class A{
public int func1(int a, int b){
return a-b;
}
}

public class Client{
public static void main(String[] args){
A a = new A();
System.out.println("100-50="+a.func1(100, 50));
System.out.println("100-80="+a.func1(100, 80));
}
}
運行結果：
100-50=50
100-80=20
後來，咱們須要增長一個新的功能：完成兩數相加，而後再與100求和，由類B來負責。即類B須要完成兩個功能：
兩數相減。
兩數相加，而後再加100。
因爲類A已經實現了第一個功能，因此類B繼承類A後，只須要再完成第二個功能就能夠了，代碼以下：
class B extends A{
public int func1(int a, int b){
return a+b;
}

public int func2(int a, int b){
return func1(a,b)+100;
}
}

public class Client{
public static void main(String[] args){
B a = new B();
System.out.println("100-50="+b.func1(100, 50));
System.out.println("100-80="+b.func1(100, 80));
System.out.println("100+20+100="+b.func2(100, 20));
}
}
類B完成後，運行結果：
100-50=150
100-80=180
100+20+100=220
咱們發現本來運行正常的相減功能發生了錯誤。緣由就是類B在給方法起名時無心中重寫了父類的方法，形成全部運行相減功能的代碼所有調用了類B重寫後的方法，形成本來運行正常的功能出現了錯誤。在本例中，引用基類A完成的功能，換成子類B以後，發生了異常。在實際編程中，咱們經常會經過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，可是整個繼承體系的可複用性會比較差，特別是運用多態比較頻繁時，程序運行出錯的概率很是大。若是非要重寫父類的方法，比較通用的作法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合，組合等關係代替。

里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。它包含如下4層含義：
子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
子類中能夠增長本身特有的方法。
當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
看上去很難以想象，由於咱們會發如今本身編程中經常會違反里氏替換原則，程序照樣跑的好好的。因此你們都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？
後果就是：你寫的代碼出問題的概率將會大大增長。

依賴倒置原則（Dependence Inversion Principle）
定義：高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。
問題由來：類A直接依賴類B，假如要將類A改成依賴類C，則必須經過修改類A的代碼來達成。這種場景下，類A通常是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操做；假如修改類A，會給程序帶來沒必要要的風險。
解決方案：將類A修改成依賴接口I，類B和類C各自實現接口I，類A經過接口I間接與類B或者類C發生聯繫，則會大大下降修改類A的概率。
依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。
依賴倒置原則的中心思想是面向接口編程，咱們依舊用一個例子來講明面向接口編程比相對於面向實現編程好在什麼地方。場景是這樣的，母親給孩子講故事，只要給她一本書，她就能夠照着書給孩子講故事了。代碼以下：
class Book{
public String getContent(){
return "好久好久之前有一個阿拉伯的故事……";
}
}

class Mother{
public void narrate(Book book){
System.out.println("媽媽開始講故事");
System.out.println(book.getContent());
}
}

public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
}
}
運行結果
媽媽開始講故事
好久好久之前有一個阿拉伯的故事……
運行良好，假若有一天，需求變成這樣：不是給書而是給一份報紙，讓這位母親講一下報紙上的故事。
class Newspaper{
public String getContent(){
return "林書豪38+7領導尼克斯擊敗湖人……";
}
}
這位母親卻辦不到，由於她竟然不會讀報紙上的故事，這太荒唐了，只是將書換成報紙，竟然必需要修改Mother才能讀。假如之後需求換成雜誌呢？換成網頁呢？還要不斷地修改Mother，這顯然不是好的設計。緣由就是Mother與Book之間的耦合性過高了，必須下降他們之間的耦合度才行。
咱們引入一個抽象的接口IReader。讀物，只要是帶字的都屬於讀物。
interface IReader{
public String getContent();
}
Mother類與接口IReader發生依賴關係，而Book和Newspaper都屬於讀物的範疇，他們各自都去實現IReader接口，這樣就符合依賴倒置原則了，代碼修改成：

class Newspaper implements IReader {
public String getContent(){
return "林書豪17+9助尼克斯擊敗老鷹……";
}
}
class Book implements IReader{
public String getContent(){
return "好久好久之前有一個阿拉伯的故事……";
}
}

class Mother{
public void narrate(IReader reader){
System.out.println("媽媽開始講故事");
System.out.println(reader.getContent());
}
}

public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
mother.narrate(new Newspaper());

}
}
運行結果
媽媽開始講故事
好久好久之前有一個阿拉伯的故事……
媽媽開始講故事
林書豪17+9助尼克斯擊敗老鷹……
這樣修改後，不管之後怎樣擴展Client類，都不須要再修改Mother類了。這只是一個簡單的例子，實際狀況中，表明高層模塊的Mother類將負責完成主要的業務邏輯，一旦須要對它進行修改，引入錯誤的風險極大。因此遵循依賴倒置原則能夠下降類之間的耦合性，提升系統的穩定性，下降修改程序形成的風險。
採用依賴倒置原則給多人並行開發帶來了極大的便利，好比上例中，本來Mother類與Book類直接耦合時，Mother類必須等Book類編碼完成後才能夠進行編碼，由於Mother類依賴於Book類。修改後的程序則能夠同時開工，互不影響，由於Mother與Book類一點關係也沒有。參與協做開發的人越多、項目越龐大，採用依賴致使原則的意義就越重大。如今很流行的TDD開發模式就是依賴倒置原則最成功的應用。
傳遞依賴關係有三種方式，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式必定不會陌生。
在實際編程中，咱們通常須要作到以下3點：
低層模塊儘可能都要有抽象類或接口，或者二者都有。
變量的聲明類型儘可能是抽象類或接口。
使用繼承時遵循里氏替換原則。
總之，依賴倒置原則就是要咱們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。
設計模式

接口隔離原則（Interface Segregation Principle）
定義：客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。
問題由來：類A經過接口I依賴類B，類C經過接口I依賴類D，若是接口I對於類A和類B來講不是最小接口，則類B和類D必須去實現他們不須要的方法。
解決方案：將臃腫的接口I拆分爲獨立的幾個接口，類A和類C分別與他們須要的接口創建依賴關係。也就是採用接口隔離原則。
舉例來講明接口隔離原則：數據結構

（圖1 未遵循接口隔離原則的設計）
這個圖的意思是：類A依賴接口I中的方法一、方法二、方法3，類B是對類A依賴的實現。類C依賴接口I中的方法一、方法四、方法5，類D是對類C依賴的實現。對於類B和類D來講，雖然他們都存在着用不到的方法（也就是圖中紅色字體標記的方法），但因爲實現了接口I，因此也必需要實現這些用不到的方法。對類圖不熟悉的能夠參照程序代碼來理解，代碼以下：

interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}

class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}

class B implements I{
public void method1() {
System.out.println("類B實現接口I的方法1");
}
public void method2() {
System.out.println("類B實現接口I的方法2");
}
public void method3() {
System.out.println("類B實現接口I的方法3");
}
//對於類A來講，method4和method5不是必需的，可是因爲接口A中有這兩個方法，
//因此在實現過程當中即便這兩個方法的方法體爲空，也要將這兩個沒有做用的方法進行實現。
public void method4() {}
public void method5() {}
}

class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}

class D implements I{
public void method1() {
System.out.println("類D實現接口I的方法1");
}
//對於類C來講，method2和method3不是必需的，可是因爲接口A中有這兩個方法，
//因此在實現過程當中即便這兩個方法的方法體爲空，也要將這兩個沒有做用的方法進行實現。
public void method2() {}
public void method3() {}

public void method4() {
System.out.println("類D實現接口I的方法4");
}
public void method5() {
System.out.println("類D實現接口I的方法5");
}
}

public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());

C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D()); }
}

能夠看到，若是接口過於臃腫，只要接口中出現的方法，無論對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。若是將這個設計修改成符合接口隔離原則，就必須對接口I進行拆分。在這裏咱們將原有的接口I拆分爲三個接口，拆分後的設計如圖2所示：架構

（圖2 遵循接口隔離原則的設計）
照例貼出程序的代碼，供不熟悉類圖的朋友參考：
interface I1 {
public void method1();
}

interface I2 {
public void method2();
public void method3();
}

interface I3 {
public void method4();
public void method5();
}

class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}

class B implements I1, I2{
public void method1() {
System.out.println("類B實現接口I1的方法1");
}
public void method2() {
System.out.println("類B實現接口I2的方法2");
}
public void method3() {
System.out.println("類B實現接口I2的方法3");
}
}

class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}

class D implements I1, I3{
public void method1() {
System.out.println("類D實現接口I1的方法1");
}
public void method4() {
System.out.println("類D實現接口I3的方法4");
}
public void method5() {
System.out.println("類D實現接口I3的方法5");
}
}

接口隔離原則的含義是：創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用。本文例子中，將一個龐大的接口變動爲3個專用的接口所採用的就是接口隔離原則。在程序設計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設計時對外部設定的「契約」，經過分散定義多個接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。
說到這裏，不少人會覺的接口隔離原則跟以前的單一職責原則很類似，其實否則。其一，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離。其二，單一職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序總體框架的構建。
採用接口隔離原則對接口進行約束時，要注意如下幾點：
接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計靈活性是不掙的事實，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度。
爲依賴接口的類定製服務，只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。
提升內聚，減小對外交互。使接口用最少的方法去完成最多的事情。
運用接口隔離原則，必定要適度，接口設計的過大或太小都很差。設計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這一原則。

迪米特法則（Law Of Demeter）
定義：一個對象應該對其餘對象保持最少的瞭解。
問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。
解決方案：儘可能下降類與類之間的耦合。
自從咱們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內聚。不管是面向過程編程仍是面向對象編程，只有使各個模塊之間的耦合儘可能的低，才能提升代碼的複用率。低耦合的優勢不言而喻，可是怎麼樣編程才能作到低耦合呢？那正是迪米特法則要去完成的。
迪米特法則又叫最少知道原則，最先是在1987年由美國Northeastern University的Ian Holland提出。通俗的來說，就是一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。
舉一個例子：有一個集團公司，下屬單位有分公司和直屬部門，如今要求打印出全部下屬單位的員工ID。先來看一下違反迪米特法則的設計。

//總公司員工
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}

//分公司員工
class SubEmployee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}

class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//爲分公司人員按順序分配一個ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
}

class CompanyManager{

public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//爲總公司人員按順序分配一個ID
emp.setId("總公司"+i);
list.add(emp);
}
return list;
}

public void printAllEmployee(SubCompanyManager sub){
List<SubEmployee> list1 = sub.getAllEmployee();
for(SubEmployee e:list1){
System.out.println(e.getId());
}

List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}

public class Client{
public static void main(String[] args){
CompanyManager e = new CompanyManager();
e.printAllEmployee(new SubCompanyManager());
}
}
如今這個設計的主要問題出在CompanyManager中，根據迪米特法則，只與直接的朋友發生通訊，而SubEmployee類並非CompanyManager類的直接朋友（以局部變量出現的耦合不屬於直接朋友），從邏輯上講總公司只與他的分公司耦合就好了，與分公司的員工並無任何聯繫，這樣設計顯然是增長了沒必要要的耦合。按照迪米特法則，應該避免類中出現這樣非直接朋友關係的耦合。修改後的代碼以下:
class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//爲分公司人員按順序分配一個ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
public void printEmployee(){
List<SubEmployee> list = this.getAllEmployee();
for(SubEmployee e:list){
System.out.println(e.getId());
}
}
}

class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//爲總公司人員按順序分配一個ID
emp.setId("總公司"+i);
list.add(emp);
}
return list;
}

public void printAllEmployee(SubCompanyManager sub){
sub.printEmployee();
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}
修改後，爲分公司增長了打印人員ID的方法，總公司直接調用來打印，從而避免了與分公司的員工發生耦合。
迪米特法則的初衷是下降類之間的耦合，因爲每一個類都減小了沒必要要的依賴，所以的確能夠下降耦合關係。可是凡事都有度，雖然能夠避免與非直接的類通訊，可是要通訊，必然會經過一個「中介」來發生聯繫，例如本例中，總公司就是經過分公司這個「中介」來與分公司的員工發生聯繫的。過度的使用迪米特原則，會產生大量這樣的中介和傳遞類，致使系統複雜度變大。因此在採用迪米特法則時要反覆權衡，既作到結構清晰，又要高內聚低耦合。

開閉原則（Open Close Principle）
定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
問題由來：在軟件的生命週期內，由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使咱們不得不對整個功能進行重構，而且須要原有代碼通過從新測試。
解決方案：當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。
開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我「你進行設計的時候必定要遵照開閉原則」，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。
在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的「平均得分」，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。
其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。
說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴咱們實現類要職責單一；里氏替換原則告訴咱們不要破壞繼承體系；依賴倒置原則告訴咱們要面向接口編程；接口隔離原則告訴咱們在設計接口的時候要精簡單一；迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。
最後說明一下如何去遵照這六個原則。對這六個原則的遵照並非是和否的問題，而是多和少的問題，也就是說，咱們通常不會說有沒有遵照，而是說遵照程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是同樣，制定這六個原則的目的並非要咱們刻板的遵照他們，而須要根據實際狀況靈活運用。對他們的遵照程度只要在一個合理的範圍內，就算是良好的設計。咱們用一幅圖來講明一下。框架