我經常遇到沒有聽說過 SOLID 原則的開發人員（我們 。 — Transl.）或面向對象編程（OOP），或者聽說過它們，但在實踐中沒有使用它們。 本文介紹了 OOP 原則對開發人員日常工作有幫助的好處。 其中一些是眾所周知的，另一些則不是那麼出名，因此本文對於初學者和經驗豐富的程序員都將很有用。
提醒： 對於所有 Habr 讀者 - 使用 Habr 促銷代碼註冊任何 Skillbox 課程可享受 10 盧布折扣。
技能箱推薦： 教育在線課程 .
DRY（不要重複自己）
這是一個相當簡單的原則，其本質從名稱中就可以清楚地看出：“不要重複自己”。 對於程序員來說，這意味著需要避免重複代碼，以及在工作中使用抽象的機會。
如果代碼中有兩個重複的部分，則應將它們合併為一個方法。 如果多次使用硬編碼值，則值得將其轉換為公共常量。
為了簡化代碼並使其更易於維護，這是必要的，這是 OOP 的主要目標。 您也不應該過度使用聯合，因為相同的代碼不會同時通過 OrderId 和 SSN 的驗證。
封裝變更
大多數公司的軟件產品都在不斷發展。 這意味著需要對代碼進行更改，需要對其進行支持。 通過使用封裝，您可以讓您的生活變得更輕鬆。 這將使您能夠更有效地測試和維護現有的代碼庫。 .
如果你用Java編寫，那麼 .
開閉原則
通過閱讀以下語句可以輕鬆記住這一原則：“軟件實體（類、模塊、函數等）應該對擴展開放，但對修改關閉。” 實際上，這意味著他們可以允許在不更改源代碼的情況下更改其行為。
當源代碼的更改需要代碼修訂、單元測試和其他過程時，這一原則很重要。 遵循開閉原則的代碼在擴展時不會改變，因此問題要少得多。
這是違反此原則的代碼示例。
如果您需要更改其中的某些內容，則需要花費大量時間，因為與所需片段相關的所有代碼部分都必須更改。
順便說一句，開放-封閉是 SOLID 的原則之一。
單一職責原則 (SRP)
SOLID 集的另一個原則。 它指出“只有一個原因會導致階級的變化。” 該類只解決一個問題。 它可能有多種方法，但每種方法僅用於解決一個常見問題。 所有方法和屬性都應該只服務於此。
這一原則的價值在於它放鬆了單個軟件組件和代碼之間的耦合。 如果向一個類添加多個功能，則會引入兩個功能之間的關係。 因此，如果您更改其中一個，則很可能會破壞與第一個相關的第二個。 這意味著增加測試週期，以便提前發現所有問題。
依賴倒置原則（DIP）
上面是一個代碼示例，其中 AppManager 依賴於 EventLogWriter，而 EventLogWriter 又與 AppManager 緊密耦合。 如果您需要以不同的方式顯示通知，無論是推送、短信還是電子郵件，您需要更改 AppManager 類。
使用DIP可以解決這個問題。 因此，我們請求一個 EventLogWriter，而不是 AppManager，它將使用框架輸入。
DIP 使得可以通過更改依賴模塊輕鬆地用其他模塊替換單個模塊。 這使得更改一個模塊而不影響其他模塊成為可能。
組合而不是繼承
重用代碼主要有兩種方式：繼承和組合，兩者都有各自的優點和缺點。 通常第二個是首選，因為它更靈活。
組合使您能夠通過設置類的屬性來在運行時更改類的行為。 在實現接口時，使用多態性，這提供了更靈活的實現。
甚至 Joshua Bloch 的《Effective Java》也建議選擇組合而不是繼承。
Barbara Liskov 替換原則 (LSP)
SOLID 工具包的另一個原則。 它規定子類型必須可以替代超類型。 也就是說，適用於超類的方法和函數應該能夠適用於其子類而不會出現問題。
LSP 與單一責任原則和共享責任原則相關。 如果一個類比子類提供更多的功能，那麼後者將不支持某些功能，從而違反了這一原則。
下面是一段與LSP相矛盾的代碼。
area(Rectangle r) 方法計算 Rectangle 的面積。 執行Square後程序會崩潰，因為這裡的Square不是矩形。 根據 LSP 原則，使用基類引用的函數應該能夠使用派生類的對象，而無需額外的指令。
這一原則是子類型的具體定義，由 Barbara Liskov 在 1987 年題為“數據抽象和層次結構”的會議主題演講中提出，因此得名。
接口分離原則 (ISP)
另一個堅實的原則。 根據它，不應該實現未使用的接口。 遵循這一原則有助於系統在操作邏輯發生變化時保持靈活性並適合重構。
最常見的情況是，當界面同時包含多個功能，而客戶端只需要其中一個功能時，就會發生這種情況。
由於編寫接口是一項艱鉅的任務，因此在工作完成後更改它而不破壞任何內容將是一個挑戰。
Java中ISP原則的優點是所有方法都必須先實現，然後才能被類使用。 因此，該原理使得減少方法數量成為可能。
為接口編程，而不是為實現編程
這裡的一切從名字就可以看出來。 應用這一原則可以創建靈活的代碼，可以與接口的任何新實現一起使用。
您應該對變量、返回類型或方法參數類型使用接口類型。 一個例子是使用 SuperClass 而不是 SubClass。
那是：
列表數字= getNumbers();
但不是：
ArrayList 數字 = getNumbers();
這是上面討論的內容的實際實現。
委託原則
一個常見的例子是 Java 中的 equals() 和 hashCode() 方法。 當需要比較兩個對象時，這一操作將委託給相應的類而不是客戶端類。
該原理的優點是沒有重複代碼，改變行為也相對簡單。 它也適用於事件委託。
所有這些原則可以讓你編寫出更加靈活、美觀、可靠、高內聚、低耦合的代碼。 當然，理論是好的，但是對於開發人員來說，要真正運用所學到的知識，還需要實踐。 一旦掌握了 OOP 原則，下一步可能就是學習設計模式來解決常見的軟件開發問題。
技能箱推薦：
- 實踐課程 .
- 應用在線課程 .
- 兩年實踐課程 .
來源： www.habr.com