面向對象之六大設計原則

六大設計原則

1、單一職責原則

    1.定義：應該有且僅有一個緣由引發類的變動。

    2.單一職責的好處

        a.類的複製性下降，實現什麼職責都有清晰明確的定義

        b.可讀性提升，複雜性下降，那固然可讀性提升了

        c.可維護性的提升，可讀性提升，固然更容易維護

        d.變動引發的風險下降，自己變動是必不可少的，接口的單一職責作的好，一個接口修改只針對響應的實現類有影響，對其餘接口無影響，對系統的擴展性和維護性都有很是大的幫助

    3.總結：現實中想要所有按照單一職責原則很難在項目中獲得提現，須要考慮的問題比較多，環境、工做量、人員技術水平以及資源等等；對於接口再設計的時候必定要作到單一；而對於實現類就須要多方面考慮；生搬硬套單一職責原則會引發類的劇增，反而給維護帶來很是多的麻煩；俗話說原則是死的人是活的；具體問題還需據對應對

    4.結合咱們酷客多產品接口設計案列，很是明顯能夠體驗出單一職責的好處

        例如：酷客多小程序產品詳情頁面，相對將頁面價格信息和促銷信息數據的獲取獨立成兩個單獨接口；酷客多營銷插件的更新迭代是比較頻繁，不時新增一種營銷插件；而將促銷信息接口獨立出後，後續不管增長多少種插件，也只須要調整促銷信息接口便可，對應商品詳情其餘數據接口無需任何改動。

 

2、里氏替換原則

    1.定義：

        a.若是對每個類型爲S的對象01，都有類型爲T的對象02，使得以T定義的全部程序P在全部的對象01都帶換成02時，程序P的行爲沒有發生變化，那麼類型S是類型T的子類型

        b.全部引用基類的地方必須能透明地使用其子類的對象；通俗的說，就是全部能使用父類的地方均可以替換爲子類，不會產生任何錯誤或異常，可是反過來就不行了，有子類出現的地方，父類未必就能適應

    2.規範:

        a.子類必須徹底實現父類的方法

            i.作系統設計時，常常會定義一個接口或抽象類，而後編碼實現，調用類則直接傳入接口或抽象類，這裏就是使用了里氏替換原則

            ii.在類種調用其它類時務必要使用父類或接口，若是不能使用父類或接口，則說明類的設計已經違背了LSP原則

            iii.若是子類不能完整地實現父類的方法，或者父類的某些方法在子類中已經發生「畸變」，則建議斷開負責繼承關係，採用依賴、彙集、組合等關係代替繼承

        b.子類能夠有本身的個性,子類同時也能夠有屬於本身的屬性和方法

        c.覆蓋或實現父類的方法時輸入參數能夠被放大

        d.覆寫或實現父類的方法時輸出結果能夠被縮小

     

 

3、依賴倒置原則

    1.定義：

        a.高層模塊不該該依賴底層模塊，兩則都應該依賴其抽象

        b.抽象不該該依賴細節

            i.什麼是抽象:抽象就是指接口或抽象類，二者都是不能直接被實例化的

            ii.什麼是細節:細節就是實現類，實現接口或繼承抽象類而產生的類就是細節，特色就是能夠直接實例化，也就是new產生一個對象

        c.細節應該依賴抽象

    2.做用：依賴倒置原則能夠減小類間的耦合性，提升系統的穩定性，下降並行開發引發的風險，提升代碼的可讀性和可維護性

    3.依賴的三種寫法

        a.構造函數傳遞依賴對象

        b.Setter方法傳遞依賴對象

        c.接口聲明傳遞依賴對象

 

4、接口隔離原則

    1.定義:

        a.客戶端不該該依賴它不須要的接口。依賴是什麼？依賴它須要的接口，客戶端須要什麼接口就提供什麼接口，把不須要的接口剔除掉，對接口進行細化，保證接口的純潔性

        b.類間的依賴關係應該創建在最小的接口上。最小的接口也是須要細化的，接口的純潔性如上，只是一個實物的兩種不一樣的描述

    2.接口隔離原則的四層含義

        a.接口要儘可能小

        b.接口要高內聚

        c.定製服務

        d.接口設計是有限度的

    3.總結：

        a.一個接口只服務於一個子模塊或業務邏輯

        b.經過業務邏輯壓縮接口中的public方法，接口時常去回顧，儘可能讓接口達到「滿身筋骨肉」，而不是「肥嘟嘟」的一大堆方法；

        c.已經污染了的接口，儘可能去修改，若變動的風險比較大，則採用適配器模式進行轉化處理。適配器模式能夠單獨查閱設計模式一書中相關信息

        d.瞭解環境，拒絕盲從。每一個項目或產品都有特定的化境因素，別看到大師是這樣作的你就照抄；環境不一樣，接口拆分的標準就不一樣。

 

5、迪米特法則

    1.定義：迪米特法則也稱爲最小知識原則，描述的規則：一個對象應該對其餘對象有最少的瞭解，通俗的說，一個類應該對本身須要耦合或調用的類知道的最少，你的內部是如何複雜和我不要緊，我就知道你提供的這麼公開方法，我就調用這麼多，其餘一律不關心

    2.迪米特法則對類的低耦合提出了明確要求，其包含3層含義

        a.只和朋友交流。兩個對象之間的耦合就成爲朋友關係，這種關係的類型有不少，例如組合、聚合‘依賴等

        b.朋友間也是有距離的。一個類公開的屬性或方法越多，修改時涉及的面也就越大，變動引發的風險擴散也就越大，所以爲了保持距離，設計時須要反覆衡量減小public方法和屬性。

        c.是本身的就是本身的：若是一個方法放在奔雷中，既不增長類間關係，對本類不產生負面影響，那就放置在本類中

    3.總結：迪米特法則的核心觀念就類間解耦，弱耦合，只有弱耦合了之後，類的複用率才能夠提升，而這樣的要求結果回產生大量的中轉和跳轉類，致使系統的複雜性提供，同時也爲維護帶來了難度。所以，在實際項目中，須要適度地考慮這個原則，別爲了套用原則而作項目。視狀況而定。

 

6、開閉原則

1.定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

  擴展開放：意思是指當咱們針對一個需求有變化時，咱們經過擴展來實現變化，，這樣對系統的最小化開發，修改也少，風險也小

  修改關閉：關閉修改應該變化，這樣極大下降系統的風險，保持歷史代碼的純潔性，提升系統的穩定性。

    2.好處

        a.開閉原則能夠提供複用性

        b.開閉原則能夠提供可維護性

    3.總結：開閉原則是一個很是虛地原則，前面5個原則是對開閉原則地具體解釋，可是開閉原則並不侷限這麼多，它「虛」得沒有邊界，就像「好好學習，每天向上」得口號同樣，告訴咱們要好好學習，可是學什麼，怎麼學沒有告訴咱們，須要咱們去體會和掌握，開閉原則也是同樣。

 

六大設計原則總結

六大設計原則得核心實際上是開閉原則，開閉原則具備理想主義的色彩，它是面向對象設計的終極目標。所以，針對開閉原則的實現方法，一直都有面向對象設計的大師費盡心機，研究開閉原則的實現方式。而對於其餘五大設計原則，均可以看做是開閉原則的實現方法。

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　做者：酷客多小程序 劉慈