如果您熟悉面向物件的程式設計，那麼您可能已經聽說過SOLID原理。

這五項軟體開發原則是構建軟體時要遵循的準則，以便於擴充套件和維護。 它們受到軟體工程師Robert C. Martin的歡迎。

在線上有很多關於SOLID的精彩文章，但我很少看到帶有圖片的示例。 這使得像我這樣的視覺學習者在保持參與的同時學習變得有些困難。

因此，本文的主要目的是通過插圖並強調每種原理的目標來更好地理解這些原理。

您會看到，其中一些原則可能看起來很相似，但它們的目標並不相同。 即使它們是相同的，也可以在違反另一個原則的同時滿足其中一個原則。

為了使操作簡單，我將使用"類"一詞，但請注意，本文中它也可以應用於函式，方法或模組。

更新*我收到了一些有關"封閉式開放"的評論，這違反了單一責任原則。 請注意，本文的目的是要獨立於其他原則來解釋這些原則。

此外，職責（或角色）與行動不同。 在SRP中，我使用"我是畫家"，在"開閉式"中，我使用"我可以繪畫"。

注意這一點很重要，因為可以執行多個操作來履行職責（或角色）。 該類應具有一個職責（SRP），但履行該職責的功能應開放以擴充套件（OCP）。

現在開始吧！

SOLID原則

S — 單一責任

類應負單一責任

如果一個班級承擔許多責任，則增加了發生錯誤的可能性，因為更改其職責之一可能會在您不知情的情況下影響其他職責。

目標

該原則旨在區分行為，這樣，如果您的更改導致錯誤出現，則不會影響其他無關的行為。

O — 開閉

類應該開放以進行擴充套件，而封閉以進行修改

更改類的當前行為將影響使用該類的所有系統。

如果要讓類執行更多功能，理想的方法是將功能新增到已經存在的功能中，而不更改它們。

目標

該原則旨在擴充套件類的行為，而不改變該類的現有行為。 這是為了避免在使用Class的任何地方引起錯誤。

L- 利斯科夫替換原則

如果S是T的子型別，則可以將程式中型別T的物件替換為型別S的物件，而無需更改該程式的任何所需屬性。

當子類無法執行與其父類相同的操作時，可能會導致錯誤。

如果您有一個類並從中建立另一個類，則該類將成為父類，而新的類將成為子類。 子類應該能夠執行父類可以做的所有事情。 此過程稱為繼承。

子類應該能夠處理與父類相同的請求並傳遞相同的結果，或者它可以傳遞相同型別的結果。

圖片顯示父類提供咖啡（它可以是任何型別的咖啡）。 子類交付Cappucino是可以接受的，因為它是一種特殊的咖啡，但是交付水是不可接受的。

如果子類別不符合這些要求，則意味著子類別已完全更改，並且違反了這一原則。

目標

該原則旨在加強一致性，以便可以以相同的方式使用父類或其子類，而不會出現任何錯誤。

I — 介面隔離

不應強迫客戶依賴他們不使用的方法。

當要求一個類執行無用的操作時，這是浪費的，並且如果該類沒有執行那些操作的能力，則可能會產生意外的錯誤。

類應僅執行履行其職責所需的操作。 如果將來其他班級可能會使用其他任何動作，則應將其完全刪除或移至其他位置。

目標

該原則旨在將一組動作分成較小的一組，以便Class僅執行其所需的一組動作。

D — 依賴倒置

-高階模組不應依賴於低階模組。 兩者都應取決於抽象。

-抽象不應依賴細節。 細節應取決於抽象。

首先，讓我們更簡單地定義此處使用的術語

高階模組（或類）：使用工具執行動作的類。

低階模組（或類）：執行操作所需的工具

抽象：表示連線兩個類的介面。

詳細資訊：該工具如何工作

該原則表明，不應將類與用於執行動作的工具融合在一起。 而是應將其與允許工具連線到類的介面融合。

它還說，類和介面都不應該知道工具的工作方式。 但是，該工具需要滿足介面規範。

目標

該原理旨在通過引入介面來減少高階類對低階類的依賴性。

摘要

到目前為止，我們已經討論了這五個原則並突出了它們的目標。 它們將幫助您使程式碼易於調整，擴充套件和測試，幾乎沒有問題。

非常感謝您的閱讀。 我希望您對這個主題有個更好的主意，並且閱讀時和我編寫時一樣開心。

如果您有任何疑問或建議，請發表評論或通過Twitter @ ugonna_t與我聯絡。

(本文翻譯自Ugonna Thelma的文章《The S.O.L.I.D Principles in Pictures》，參考：https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898)