宣告：本系列部落格參考資料《大話設計模式》，作者程傑。

     一般認為遵從以下六大原則的程式碼是易擴充套件可複用的程式碼：

     這六大原則任何面向物件的語言都應該遵守的，要想讓你的程式碼易擴充套件高服用就儘量去滿足這六大原則吧，不一定嚴格按照某種設計模式，但是如果你的程式碼符合這六大原則，那麼你的程式碼就是好程式碼了，好的程式碼不一定是嚴格按照設計模式寫的程式碼。

         1.單一職責

        定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。

         場景：

        修改：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險，結構如下圖：

      優點：

1）、可以降低類的複雜度，一個類只負責一項職責，邏輯簡單；

2）、提高類的可讀性，提高系統的可維護性；

3）、變更引起的風險降低，變更是必然的。

    2.里氏代換原則

     定義：所有引用基類的地方必須能透明地使用其子類的物件，也就是說子類可以擴充套件父類的功能，但不能改變父類原有的功能

     場景：有一功能P1，由類A完成。現需要將功能P1進行擴充套件，擴充套件後的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障，如下圖：

        CountPriceByJKL類繼承於CountPrice類，CountPriceByJKL重寫了Count()方法，這樣可能影響到原來Count方法的功能。

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

        3.依賴倒置原則

        定義：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

        此處理解起來是最困難的，一般會在專案框架的搭建的時候用到，例如，業務邏輯層相對於資料層是高層模組，因為業務邏輯層需要呼叫資料層去連線資料庫，但是要做到可擴充套件高複用，儘量不要讓業務邏輯層依賴資料層，可以在資料層抽象出一個介面，讓業務邏輯層依賴於這個抽象介面。

         場景：類A（高層模組）直接依賴類B（低層模組），假如要將類A改為依賴類C（低層模組），則必須通過修改類A的程式碼來達成。這種場景下，類A一般是高層模組，負責複雜的業務邏輯；類B和類C是低層模組，負責基本的原子操作；假如修改類A，會給程式帶來不必要的風險。

          AutoSystem類直接依賴於HondaCar與FordCar兩個類，這樣就產生了一個高耦合，AutoSystem類想操控HondaCar或者FordCar必須直接建立相應物件。

         修改：將類A修改為依賴介面I，類B和類C各自實現介面I，類A通過介面I間接與類B或者類C發生聯絡，則會大大降低修改類A的機率，如下圖：

           經過此番修改，Honda與Ford實現ICar介面，提供了Run、Stop以及Turn功能方法，AutoSystem依賴ICar介面，這樣迫使AutoSystem依賴抽象介面，這就使得AutoSystem類能夠應對更多的需求變化。

          優點：

1）、低層模組儘量都要有抽象類或介面，或者兩者都有。

2）、變數的宣告型別儘量是抽象類或介面。

3）、使用繼承時遵循里氏替換原則。

           4.介面隔離原則

           定義：客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。

           場景：類A通過介面I依賴類B，類C通過介面I依賴類D，如果介面I對於類A和類B來說不是最小介面，則類B和類D必須去實現他們不需要的方法，如下圖：

　　　修改：將臃腫的介面I拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則。

　　　注意：

　　　　　1）、介面儘量小，但是要有限度。對介面進行細化可以提高程式設計靈活性   是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適度。

2）、為依賴介面的類定製服務，只暴露給呼叫的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模組提供定製服務，才能建立最小的依賴關係。

　　  ５.迪米特法則（最少知道原則）

　　定義：一個物件應該對其他物件保持最少的瞭解。

　　場景：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。

　　簡單的理解就是高內聚，一個類儘量減少對其他物件的依賴，並且這個類的方法和屬效能用私有的就儘量私有化。

　　注意：

            1）、只與直接的朋友通訊，不要和陌生人說話。

            2）、過分的使用該原則，將導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。

        6.開閉原則

        定義：一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。

        場景：在軟體的生命週期內，因為變化、升級和維護等原因需要對軟體原有程式碼進行修改時，可能會給舊程式碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有程式碼經過重新測試。

       建議：當軟體需求變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。

         更多詳情敬請關注我的視訊課程：