單一職責(zé)原則（SRP）

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

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

?

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

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

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

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

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

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

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

?

開閉原則

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

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

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

??最常用來提高代碼擴(kuò)展性的方法有：多態(tài)、依賴注入、基于接口而非實(shí)現(xiàn)編程，以及大部分的設(shè)計(jì)模式（比如，裝飾、策略、模板、職責(zé)鏈、狀態(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言的一種語法。它是一種代碼實(shí)現(xiàn)的思路。而里式替換是一種設(shè)計(jì)原則，是用來指導(dǎo)繼承關(guān)系中子類該如何設(shè)計(jì)的，子類的設(shè)計(jì)要保證在替換父類的時(shí)候，不改變原有程序的邏輯以及不破壞原有程序的正確性。

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

?

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

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

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

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

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

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

?

接口隔離原則(Interface Segregation Principle)

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

??

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

（1）一組 API 接口集合

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

（3）OOP 中的接口概念

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

?

總結(jié)

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

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