講講solid原則

           

前言

在程序設計領域， SOLID（單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉）是由羅伯特·C·馬丁在21世紀早期引入，指代了面向對象編程和麪向對象設計的五個基本原則。當這些原則被一塊兒應用時，它們使得一個程序員開發一個容易進行軟件維護和擴展的系統變得更加可能。

單一職責原則

一個類只負責一件事，也就是把關聯性強的內容聚合到一個類裏面，不摻雜其它的影響。

開放封閉原則

實體應該對擴展是開放的，對修改是封閉的。便可擴展(extension)，不可修改(modification)。

例子：開發中不少場景下會採用消息中間件解耦，如何對消息處理統一管理呢？可能剛開始考慮不全會致使後續開發無奈地採用if-else來打補丁似的完成需求，但這種狀況下常常reopen已穩定運行在線上的代碼，不可避免會有機率由於更改形成線上故障。那麼如何秉持開放封閉原則來統一處理呢？

可考慮設計將變化放在處理器上，而管理這些處理器的註冊器不可修改，若是有新的業務需求只需增長處理器處理便可。

消息註冊器

消息處理器

裏式替換原則

一個對象在其出現的任何地方，均可以用子類實例作替換，而且不會致使程序的錯誤。

經典的例子: 正方形不是長方形的子類。緣由是正方形多了一個屬性「長 == 寬」。這時，對正方形類設置不一樣的長和寬，計算面積的結果是最後設置那項的平方，而不是長*寬，從而發生了與長方形不一致的行爲。若是程序依賴了長方形的面積計算方式，並使用正方形替換了長方形，實際表現與預期不符。

接口分離原則

一個類不該該強制讓它繼承它不須要的接口，能夠將接口拆分更細粒度，有助於解耦。

         

          

裏式替換原則

一個對象在其出現的任何地方，均可以用子類實例作替換，而且不會致使程序的錯誤。

經典的例子: 正方形不是長方形的子類。緣由是正方形多了一個屬性「長 == 寬」。這時，對正方形類設置不一樣的長和寬，計算面積的結果是最後設置那項的平方，而不是長*寬，從而發生了與長方形不一致的行爲。若是程序依賴了長方形的面積計算方式，並使用正方形替換了長方形，實際表現與預期不符。

接口分離原則

一個類不該該強制讓它繼承它不須要的接口，能夠將接口拆分更細粒度，有助於解耦。

接口是設計時對外部設定的「契約」，經過分散定義多個接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。在程序設計中，接口應該專一於對某個模塊提供定製服務，屏蔽不須要的服務，接口的範圍應該適當，避免過分的隔離會致使項目過於複雜，鬆散。

依賴倒置原則

高層模塊不該該依賴於低層模塊，抽象不該該依賴於具體實現。

在微服務開發中，調用其它服務提供方的服務能夠快速的完成業務需求。可是存在服務方因業務需求變更過大、優化業務模型等種種緣由須要從新發布一版新服務，舊的服務可能會存在下線風險，而咱們業務依賴於服務方的服務，如何讓咱們儘量地少改動代碼？在設計中，能夠想到在外部模塊ext直接設計一個符合業務的接口，接口實現調用服務方遠程服務，利用Convert轉換，數據對象直接拷貝過來，保障穩定性。這符合DIP原則，可能在引入新依賴方的時候有點麻煩，可是這樣能夠很方便後續的替換服務，最大程度下降後續維護成本。

後續

點個關注，順便加點料來一篇你寫的代碼，是別人的噩夢嗎？看看會不會心緒來潮？

喜歡的讀者能夠關注路上小棧，及時獲取最新的技術文章，專一源碼分析、技術業務思考等。