單一職責原則（SRP）

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

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

?

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

1.類中的代碼行數(shù)、函數(shù)或?qū)傩赃^多，會影響代碼的可讀性和可維護性，我們就需要考慮對類進行拆分；

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

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

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

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

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

?

開閉原則

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

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

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

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

?

里式替換原則(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）出現(xiàn)的任何地方，并且保證原來程序的邏輯行為（behavior）不變及正確性不被破壞。

? ? ?多態(tài)是面向?qū)ο缶幊痰囊淮筇匦?#xff0c;也是面向?qū)ο缶幊陶Z言的一種語法。它是一種代碼實現(xiàn)的思路。而里式替換是一種設(shè)計原則，是用來指導繼承關(guān)系中子類該如何設(shè)計的，子類的設(shè)計要保證在替換父類的時候，不改變原有程序的邏輯以及不破壞原有程序的正確性。

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

?

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

子類違背父類聲明要實現(xiàn)的功能

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

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

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

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

?

接口隔離原則(Interface Segregation Principle)

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

??

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

（1）一組 API 接口集合

（2）單個 API 接口或函數(shù)

（3）OOP 中的接口概念

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

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。