單一職責原則（SRP）

??SOLID 原則并非單純的 1 個原則，而是由 5 個設計原則組成的，它們分別是：單一職責原則、開閉原則、里式替換原則、接口隔離原則和依賴反轉原則，依次對應 SOLID 中的 S、O、L、I、D 這 5 個英文字母。

? ?單一職責原則的英文是 Single Responsibility Principle，縮寫為 SRP。?A class or module should have a single responsibility。如果我們把它翻譯成中文，那就是：一個類或者模塊只負責完成一個職責（或者功能）。?不要設計大而全的類，要設計粒度小、功能單一的類。

?

??下面這幾條判斷原則，比起很主觀地去思考類是否職責單一，要更有指導意義、更具有可執行性：

1.類中的代碼行數、函數或屬性過多，會影響代碼的可讀性和可維護性，我們就需要考慮對類進行拆分；

2.類依賴的其他類過多，或者依賴類的其他類過多，不符合高內聚、低耦合的設計思想，我們就需要考慮對類進行拆分；

3.私有方法過多，我們就要考慮能否將私有方法獨立到新的類中，設置為 public 方法，供更多的類使用，從而提高代碼的復用性；

4.比較難給類起一個合適名字，很難用一個業務名詞概括，或者只能用一些籠統的 Manager、Context 之類的詞語來命名，這就說明類的職責定義得可能不夠清晰；

5.類中大量的方法都是集中操作類中的某幾個屬性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考慮將這幾個屬性和對應的方法拆分出來。

? ?實際上，不管是應用設計原則還是設計模式，最終的目的還是提高代碼的可讀性、可擴展性、復用性、可維護性等。我們在考慮應用某一個設計原則是否合理的時候，也可以以此作為最終的考量標準。

?

開閉原則

? ?擴展性是代碼質量最重要的衡量標準之一。在 23 種經典設計模式中，大部分設計模式都是為了解決代碼的擴展性問題而存在的，主要遵從的設計原則就是開閉原則。

? ?開閉原則的英文全稱是 Open Closed Principle，簡寫為 OCP。。它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我們把它翻譯成中文就是：軟件實體（模塊、類、方法等）應該“對擴展開放、對修改關閉”。那就是，添加一個新的功能應該是，在已有代碼基礎上擴展代碼（新增模塊、類、方法等），而非修改已有代碼（修改模塊、類、方法等）。

??為了盡量寫出擴展性好的代碼，我們要時刻具備擴展意識、抽象意識、封裝意識。這些“潛意識”可能比任何開發技巧都重要。

??最常用來提高代碼擴展性的方法有：多態、依賴注入、基于接口而非實現編程，以及大部分的設計模式（比如，裝飾、策略、模板、職責鏈、狀態等）。

?

里式替換原則(Liskov Substitution Principle)

??If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program。

子類對象（object of subtype/derived class）能夠替換程序（program）中父類對象（object of base/parent class）出現的任何地方，并且保證原來程序的邏輯行為（behavior）不變及正確性不被破壞。

? ? ?多態是面向對象編程的一大特性，也是面向對象編程語言的一種語法。它是一種代碼實現的思路。而里式替換是一種設計原則，是用來指導繼承關系中子類該如何設計的，子類的設計要保證在替換父類的時候，不改變原有程序的邏輯以及不破壞原有程序的正確性。

? ?子類在設計的時候，要遵守父類的行為約定（或者叫協議）。父類定義了函數的行為約定，那子類可以改變函數的內部實現邏輯，但不能改變函數原有的行為約定。這里的行為約定包括：函數聲明要實現的功能；對輸入、輸出、異常的約定；甚至包括注釋中所羅列的任何特殊說明。

?

?如下是幾個違反里式替換原則的例子，這是三種典型的違背里式替換原則的情況

子類違背父類聲明要實現的功能

子類違背父類對輸入、輸出、異常的約定

子類違背父類注釋中所羅列的任何特殊說明

? ?除此之外，判斷子類的設計實現是否違背里式替換原則，還有一個小竅門，那就是拿父類的單元測試去驗證子類的代碼。如果某些單元測試運行失敗，就有可能說明，子類的設計實現沒有完全地遵守父類的約定，子類有可能違背了里式替換原則。

??里式替換原則是用來指導，繼承關系中子類該如何設計的一個原則。

?

接口隔離原則(Interface Segregation Principle)

??Clients should not be forced to depend upon interfaces that they do not use。直譯成中文的話就是：客戶端不應該被強迫依賴它不需要的接口。其中的“客戶端”，可以理解為接口的調用者或者使用者。

??

在這條原則中，我們可以把“接口”理解為下面三種東西：

（1）一組 API 接口集合

（2）單個 API 接口或函數

（3）OOP 中的接口概念

? ? ? 單一職責原則針對的是模塊、類、接口的設計。接口隔離原則相對于單一職責原則，一方面更側重于接口的設計，另一方面它的思考角度也是不同的。接口隔離原則提供了一種判斷接口的職責是否單一的標準：通過調用者如何使用接口來間接地判定。如果調用者只使用部分接口或接口的部分功能，那接口的設計就不夠職責單一。

?

總結

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

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