0、前言

　　這一段時間一直在看設計模式，里面分多次提到幾個設計原則，看了幾次發現記不清楚，還是得自己動手總結一下吧，把書上的理論先理解寫下來再說嘍。

1、單一職責原則

• 定義：不要存在多于一個導致類變更的原因，通俗的說就是一個類只負責一項職責。
• 優點
  • 降低類的復雜度，一個類只負責一個職責，其邏輯一定會比一個類負責多項職責要簡單，同時也易于維護
  • 提高類的可讀性，提高系統的可維護性
  • 降低變更所帶來的風險；系統的變更是必然的，如果單一職責原則遵守的好，那么當修改一個功能時可以顯著降低對其他功能的影響

　　雖說我們要遵守單一職責原則，但是也不是說死板的對每一個細節都嚴格遵守，也要視情況而定：如果一個類的邏輯非常簡單且可以保證變化極小，此時可以在代碼級別上違反單一職責原則；另外當一個類中方法很少時，也可以在方法的級別上違反這一原則。（這里我這么理解單一職責原則：分為兩個層次，最高層次是類的層次，其次是方法層次上）但是如果一個類相對龐大，類中方法較多時，一定要遵守單一職責原則；寧愿在第一次擴展時花費精力完成重構，也要遵守這一原則，否則會給以后的擴展帶來不可預估的災難！

2、里式替換原則

• 定義
  • 如果對每一個類型為T1的對象o1，都有類型為T2的對象o2，使得以T1定義的所有程序P在所有的對象o1都替換為o2時，程序P的行為沒有發生變化；那么類型T2是類型T1的子類型
  • 所有引用基類的地方必須可以透明的使用其子類的對象
  • 通俗的講就是：一個軟件實體如果使用的是一個父類的話，那么一定適用于其子類，而且它察覺不出父類對象和子類對象的區別。也即在軟件里面把父類都替換成他的子類，程序的行為沒有發生任何變化。

　　繼承包含這樣一層含義：父類中凡是已經實現好的方法（區別于抽象方法），實際上是在設定一系列的規則和契約，雖然它并不要求所有的子類都必須強制遵守這些規則，但是如果子類任意對這些非抽象方法進行重寫，就會對整個繼承體系造成破壞。里式替換原則主要就是想表達這一層含義。

　　當然如果你非要重寫父類的非抽象方法，這時應該采用這樣的方式：原來的父類和子類都繼承自一個更通用的基類，原有的繼承關系去掉，轉而采用依賴、聚合、組合等關系來替代。

　　里式替換原則更通俗的說就是：子類可以擴展父類的功能，但是不能修改父類原有的功能；具體有以下4中含義：

• 子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法
• 子類可以增加自己特有的方法
• 當子類的方法重載父類的方法時，方法的前置條件（形參）要比父類方法的輸入方法更寬松
• 當子類實現父類的抽象方法時，方法的后置條件（即方法返回值）要比父類更嚴格

　　如果在開發中不遵循里式替換原則程序也照樣跑的好好地，那么也沒啥差別啊？這就錯了，這樣的后果就是你的代碼出錯的幾率會大大的增加。

3、依賴倒轉原則

• 定義：抽象不應該依賴細節，細節應該依賴于抽象（說白了就是要針對接口編程，不要對實現編程）；也即：
  • 高層模塊不應該依賴于底層模塊，二者都應該依賴于抽象；
  • 抽象不應該依賴于細節，細節應該依賴于抽象
• 依賴倒轉原則基于這樣一個事實：相對于細節實現中的多變性，抽象的東西要穩定的多；以抽象為基礎搭建起來的架構比以細節為基礎搭建起來的架構要穩定的多。具體來說（.NET+C#），抽象一般指的是接口、抽象類，細節就是具體的實現類。使用抽象的目的是制定好規范和契約，而不要涉及具體的實現，把細節交給他們的實現類來完成。

　　依賴倒轉原則的核心就是面向接口編程，傳遞依賴關系有三種方式：接口傳遞、構造方法傳遞、setter傳遞（如果用過spring框架，那么對傳遞一定會很熟悉）。在實際的開發中我們主要通過以下幾點來較好的遵守依賴倒轉原則：

• 底層模塊盡量都要有抽象類或接口，或兩者都有
• 變量的聲明類型盡量是抽象類或接口
• 使用繼承時要遵循里式替換原則

　　遵循依賴倒轉原則可以降低類之間的耦合性，提高系統穩定性，降低修改造成的風險。同時，采用依賴倒轉原則給并行開發帶來了極大的便利，參與開發的人越多、項目越龐大依賴倒轉原則意義和好處就越明顯。當前比較流行的TDD開發模式就是依賴倒置原則非常成功的應用。

4、迪米特法則

• 定義（也叫最少知道原則）
  • 如果兩個類不必直接通信，那么這兩個類就不應當發生直接的相互作用。如果一個類需要調用另一個類的方法，可以通過第三方來轉發這個調用
  • 一個對象應該保持對其他對象最少的了解

　　通俗的來講，就是一個類對自己以來的類知道的越少越好；也就是說對于被依賴的類來說，無論邏輯多么復雜，都應當把邏輯封裝在內部，對外除了提供public方法之外，不泄露其他任何信息。再通俗來說：迪米特法則就是‘只與直接的朋友通信’。那么什么是直接的朋友呢：每個對象都會與其他對象有耦合關系，只要兩個對象間出現耦合關系，我們就說兩個對象之間是朋友關系。而耦合的方式有很多，依賴、關聯、聚合、組合都是耦合關系；其中，我們稱出現成員變量、方法參數、方法返回值中的類為直接朋友，而出現在局部變量中的類則是間接朋友關系。也就是說陌生的類最好不要作為局部變量的形式出現在類的內部。

　　迪米特法則的初衷是降低類之間的耦合，但是凡事都有一個度，雖然可以避免與非直接類之間的通信，但是要通信就必須通過一個中介來發生關系；而過分的使用迪米特法則，就會產生大量這樣的中介和傳遞類，導致系統的復雜度增加。所以在使用迪米特法則時，要反復權衡，既要做到結構清晰又要高內聚低耦合。

5、開放-封閉原則

• 定義：一個軟件實體（如類、模塊、函數等）應該對擴展開放，對修改關閉；即可以擴展但是不能修改
• 當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不能通過修改已有代碼來實現變化。

　　開放-封閉原則是面向對象設計中最基礎的原則，它指導我們如何建立穩定、靈活的系統。但是他也是這幾個模式中定義最為模糊的一個，在初接觸它時，總給你一種無處下手的感覺，因為它太虛了。但是當把其他原則還有23中設計模式通讀了一遍之后，我發現可以這么理解它：開放-封閉原則是戰略，而其他的幾個原則以及設計模式就是具體的戰術；如何實現開放-封閉原則呢？要想實現一個戰略，就必須要制定合適的戰術：即，通過較好的遵守其他幾個原則以及通過合適的設計模式，最終實現一個軟件很好的開發-封閉原則。

※其他【接口隔離原則】

　　客戶端不應該依賴它不需要的接口，一個類對另一個類的依賴應該建立在最小的接口上。

　　可以這么理解：如果接口過于臃腫，那么實現他的類不管用不用的到，都必須實現接口中所有的方法，這顯然是不好的設計；這時候就需要遵循接口隔離原則對臃腫的接口進行拆分。他的原則就是：盡量建立單一的接口，盡量細化接口，接口中的方法盡量少。也就是說，我們要為各個類建立專用的接口，而不是試圖去建立一個很龐大的接口共所有依賴他的類去調用。

　　這里接口隔離原則與單一職責原則也有一定的區別，主要從以下方面來看：

• 單一職責原則注重的是職責，而接口隔離注重的是對接口依賴的隔離；
• 單一職責原則主要約束的是類，其次才是接口和方法，它主要針對的是程序中實現的細節；而接口隔離原則主要針對接口和抽象，針對程序框架的構建。

　　但是在使用接口隔離原則時也一定要適度，一定要注意：

• 接口盡量小，但是也要有限度。如果接口過小，會造成接口過多，而導致增加設計的復雜度。
• 為依賴接口的類定制服務，只暴露給調用他的類所需要的方法，他不需要的方法則要隱藏起來。只有專注的為一個模塊提供定制服務，才能建立最小的依賴關系。

　　最后的這個接口隔離原則，我的看法就是：只是從更加細小的粒度上解釋了單一職責原則。因此在這里放在最后的其他里面描述他。同時，這幾個原則現在只是對照著定義還是自己很少的開發經歷來理解，很多還無法清楚的理解和使用，后面還有很長的路需要走啊，加油！

轉載于:https://www.cnblogs.com/qingtian-jlj/p/6209157.html

總結

以上是生活随笔為你收集整理的设计模式6大原则简述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。