前言
在程式設計領域， SOLID（單一功能、開閉原則、里氏替換、介面隔離以及依賴反轉）是由羅伯特·C·馬丁在21世紀早期引入，指代了物件導向程式設計和麵向物件設計的五個基本原則。當這些原則被一起應用時，它們使得一個程式設計師開發一個容易進行軟體維護和擴充套件的系統變得更加可能。
單一職責原則
一個類只負責一件事，也就是把關聯性強的內容聚合到一個類裡面，不摻雜其它的影響。
開放封閉原則
實體應該對擴充套件是開放的，對修改是封閉的。即可擴充套件(extension)，不可修改(modification)。
例子：開發中很多場景下會採用訊息中介軟體解耦，如何對訊息處理統一管理呢？可能剛開始考慮不全會導致後續開發無奈地採用if-else來打補丁似的完成需求，但這種情況下經常reopen已穩定執行線上上的程式碼，不可避免會有機率因為更改造成線上故障。那麼如何秉持開放封閉原則來統一處理呢？
可考慮設計將變化放在處理器上，而管理這些處理器的註冊器不可修改，如果有新的業務需求只需增加處理器處理即可。
訊息註冊器
訊息處理器
裡式替換原則
一個物件在其出現的任何地方，都可以用子類例項做替換，並且不會導致程式的錯誤。
經典的例子: 正方形不是長方形的子類。原因是正方形多了一個屬性“長 == 寬”。這時，對正方形類設定不同的長和寬，計算面積的結果是最後設定那項的平方，而不是長*寬，從而發生了與長方形不一致的行為。如果程式依賴了長方形的面積計算方式，並使用正方形替換了長方形，實際表現與預期不符。
介面分離原則
一個類不應該強制讓它繼承它不需要的介面，可以將介面拆分更細粒度，有助於解耦。
裡式替換原則
一個物件在其出現的任何地方，都可以用子類例項做替換，並且不會導致程式的錯誤。
經典的例子: 正方形不是長方形的子類。原因是正方形多了一個屬性“長 == 寬”。這時，對正方形類設定不同的長和寬，計算面積的結果是最後設定那項的平方，而不是長*寬，從而發生了與長方形不一致的行為。如果程式依賴了長方形的面積計算方式，並使用正方形替換了長方形，實際表現與預期不符。
介面分離原則
一個類不應該強制讓它繼承它不需要的介面，可以將介面拆分更細粒度，有助於解耦。
介面是設計時對外部設定的“契約”，通過分散定義多個介面，可以預防外來變更的擴散，提高系統的靈活性和可維護性。在程式設計中，介面應該專注於對某個模組提供定製服務，遮蔽不需要的服務，介面的範圍應該適當，避免過度的隔離會導致專案過於複雜，鬆散。
依賴倒置原則
高層模組不應該依賴於低層模組，抽象不應該依賴於具體實現。
在微服務開發中，呼叫其它服務提供方的服務可以快速的完成業務需求。但是存在服務方因業務需求變動過大、優化業務模型等種種原因需要重新發布一版新服務，舊的服務可能會存在下線風險，而我們業務依賴於服務方的服務，如何讓我們儘可能地少改動程式碼？在設計中，可以想到在外部模組ext直接設計一個符合業務的介面，介面實現呼叫服務方遠端服務，利用Convert轉換，資料物件直接拷貝過來，保障穩定性。這符合DIP原則，可能在引入新依賴方的時候有點麻煩，但是這樣可以很方便後續的替換服務，最大程度降低後續維護成本。
後續
點個關注，順便加點料來一篇你寫的程式碼，是別人的噩夢嗎？看看會不會心緒來潮？
喜歡的讀者可以關注路上小棧，及時獲取最新的技術文章，專注原始碼分析、技術業務思考等。