設(shè)計(jì)模式的六大原則是什么

單一職責(zé)原則

單一職責(zé)原則（Single Responsibility Principle）

There should never be more than one reason for a class to change.（有且僅有一個(gè)原因可以引起類的變更）

不管讓我干啥，我都只干一件事，你讓我下樓取快遞，順便將垃圾帶下去，對不起，我不干，我只取快遞。

優(yōu)點(diǎn)：

• 類的復(fù)雜性降低，實(shí)現(xiàn)什么職責(zé)都有清晰明確的定義；
• 可讀性提高，復(fù)雜性降低，那當(dāng)然可讀性提高了；
• 可維護(hù)性提高，可讀性提高，那當(dāng)然更容易維護(hù)了；
• 變更引起的風(fēng)險(xiǎn)降低，變更是必不可少的，如果接口的單一職責(zé)做得好，一個(gè)接口修改只對相應(yīng)的實(shí)現(xiàn)類有影響，對其他的接口無影響，這對系統(tǒng)的擴(kuò)展性、維護(hù)性都有非常大的幫助。 

接口隔離原則

接口隔離原則（Interface Segregation Principle）

1、Clients should not be forced to depend upon interfaces that they don't use.（客戶端不應(yīng)該依賴它不需要的接口）

2、The dependency of one class to another one should depend on the smallest possible interface.（類間的依賴關(guān)系應(yīng)該建立在最小的接口上）

舉個(gè)例子，類A 通過 Interface1 依賴類B，方法1，方法2，方法3；類B 通過 Interface1 依賴D，方法1，方法4，方法5，看下未使用接口隔離原則和使用了接口隔離原則發(fā)生了什么變化。

依賴倒置原則

依賴倒置原則（Dependence Inversion Principle）

1、High level modules should not depend upon low level modules.Both should depend upon abstractions. （高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴其抽象）

2、Abstractions should not depend upon details. （抽象不應(yīng)該依賴細(xì)節(jié)）

3、Details should depend upon abstractions. （細(xì)節(jié)應(yīng)該依賴抽象）

舉個(gè)例子，類A 直接依賴 類B，假如要將 類A 改為依賴 類C，則必須通過修改 類A 的代碼來達(dá)成。這種場景下，類A一般是高層模塊，負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯；類B 和類C 是低層模塊，負(fù)責(zé)基本的原子操作；假如修改類A，會給程序帶來不必要的風(fēng)險(xiǎn)。

解決方案：將 類A 修改為依賴 接口Interface1，類B 和 類C 各自實(shí)現(xiàn) 接口Interface1，類A 通過 接口Interface1 間接與 類B 或者 類C 發(fā)生聯(lián)系，則會大大降低修改 類A 的幾率。

里氏替換原則

里氏替換原則（Liskov Substitution Principle）

1、If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果對每一個(gè)類型為 S 的對象o1，都有類型為 T 的對象 o2，使得以 T 定義的所有程序 P 在所有的對象 o1 都代換成 o2 時(shí)，程序 P 的行為沒有發(fā)生變化，那么類型 S 是類型 T 的子類型）

2、Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（所有引用基類的地方必須能透明地使用其子類的對象）

舉個(gè)例子，有一功能 P1，由 類A 完成，現(xiàn)需要將功能 P1 進(jìn)行擴(kuò)展，擴(kuò)展后的功能為 P，其中 P 由原有功能 P1 與新功能 P2 組成，新功能 P 由 類A 的 子類B 來完成，則 子類B 在完成新功能 P2 的同時(shí)，有可能會導(dǎo)致原有功能 P1 發(fā)生故障。

解決方案：當(dāng)使用繼承時(shí)，遵循里氏替換原則。類B 繼承 類A 時(shí)，除添加新的方法完成新增功能 P2 外，盡量不要重寫 父類A 的方法，也盡量不要重載父類A的方法。

繼承包含這樣一層含義：父類中凡是已經(jīng)實(shí)現(xiàn)好的方法，實(shí)際上是在設(shè)定一系列的規(guī)范和契約，雖然它不強(qiáng)制要求所有的子類必須遵從這些契約，但是如果子類對這些方法任意修改，就會對整個(gè)繼承體系造成破壞，而里氏替換原則就是表達(dá)了這一層含義。

繼承作為面向?qū)ο笕筇匦灾?，在給程序設(shè)計(jì)帶來巨大便利的同時(shí)，也帶來了弊端。比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加了對象間的耦合性，如果一個(gè)類被其他的類所繼承，則當(dāng)這個(gè)類需要修改時(shí)，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能會產(chǎn)生故障。

優(yōu)點(diǎn)：

• 代碼共享，減少創(chuàng)建類的工作量，每個(gè)子類都擁有父類的方法和屬性；
• 提高代碼的重用性，可擴(kuò)展性。
• 提高產(chǎn)品或項(xiàng)目的開放性。

迪米特法則

迪米特法則（Law of Demeter）

1、Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.（每個(gè)單元對于其他的單元只能擁有有限的知識：只是與當(dāng)前單元緊密聯(lián)系的單元）

2、Each unit should only talk to its friends; don't talk to strangers.（每個(gè)單元只能和它的朋友交談：不能和陌生單元交談）

3、Only talk to your immediate friends.（只和自己直接的朋友交談）

舉個(gè)例子，我們通過 手機(jī) 閱讀 微信讀書 APP 內(nèi)的 書籍，如何設(shè)計(jì)類的編寫？

手機(jī)類 和 書籍類，這兩個(gè)不能直接發(fā)生調(diào)用關(guān)系，需要 手機(jī)類 和 微信讀書 APP 類先發(fā)生調(diào)用關(guān)系，然后微信讀書 APP 類 再和 書籍 類可以發(fā)生調(diào)用關(guān)系，這樣才遵循迪米特法則。

開閉原則

開閉原則（Open Closed Principle）

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.（軟件中的對象（類，模塊，函數(shù)等等）應(yīng)該對于擴(kuò)展是開放的，但是對于修改是封閉的）

在軟件的生命周期內(nèi)，因?yàn)樽兓?、升級和維護(hù)等原因需要對軟件原有代碼進(jìn)行修改時(shí)，可能會給舊代碼中引入錯(cuò)誤，也可能會使我們不得不對整個(gè)功能進(jìn)行重構(gòu)，并且需要原有代碼經(jīng)過重新測試。

解決方案：當(dāng)軟件需要變化時(shí)，盡量通過擴(kuò)展軟件實(shí)體的行為來實(shí)現(xiàn)變化，而不是通過修改已有的代碼來實(shí)現(xiàn)變化。