設計模式的六大原則是什么

單一職責原則

單一職責原則（Single Responsibility Principle）

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

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

優(yōu)點：

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

接口隔離原則

接口隔離原則（Interface Segregation Principle）

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

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

舉個例子，類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. （高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象）

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

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

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

解決方案：將 類A 修改為依賴 接口Interface1，類B 和 類C 各自實現(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.（如果對每一個類型為 S 的對象o1，都有類型為 T 的對象 o2，使得以 T 定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 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.（所有引用基類的地方必須能透明地使用其子類的對象）

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

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

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

繼承作為面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了弊端。比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加了對象間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能會產(chǎn)生故障。

優(yōu)點：

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

迪米特法則

迪米特法則（Law of Demeter）

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

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

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

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

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

開閉原則

開閉原則（Open Closed Principle）

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

在軟件的生命周期內(nèi)，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經(jīng)過重新測試。

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