似乎無法理解SOLID原則和設計模式

Question

我試圖最近進入OOP，並且在SOLID原理和設計模式方面遇到問題。我明白爲什麼人們會使用它們，我也很想使用它們，但是我無法將自己的課程發展爲規範。我真的很感激任何能夠幫助我理解這些的東西。

Answer 1

我在大學讀過一堂課，花了兩個星期的時間學習設計模式，並且讀了Gang of Four這本書無濟於事。瞭解每種模式的服務內容以及如何使用它們來適應我的問題對我來說非常困難，這是一個在面向對象編程方面沒有太多經驗的開發人員。

真正讓它點擊的書是Head First Design Patterns。它首先展示一個問題，開發人員考慮的不同方法，然後他們如何最終使用設計模式來解決問題。它使用一種非常簡單的語言，並保持這本書非常吸引人。設計模式最終成爲描述解決方案的一種方式，但您不需要就可以讓使您的類適應解決方案。可以把它們看作是一個指導方針，爲各種問題提供了一個很好的解決方案。

講起SOLID：

1. 單一職責。一個班級應該只有一個責任。這意味着，例如，一個Person類只應該擔心關於該人本身的域問題，而不是例如它在數據庫中的持久性。爲此，您可能想要使用PersonDAO。 Person類可能希望盡其最短的責任。如果一個類正在使用太多的外部依賴（也就是其他類），那就是這個類承擔了太多責任的症狀。當開發人員嘗試使用對象對現實世界進行建模並採用它時，通常會出現這個問題。鬆散耦合的應用程序通常不太容易導航，並且不能準確模擬真實世界的工作方式。
2. 開放已關閉。類應該是可擴展的，但不可修改。這意味着給一個類增加一個新的字段很好，但改變現有的東西卻不行。程序上的其他組件可能取決於所述字段。
3. Liskov替代。如果通過了一個子類的狗和一個子類的貓，那麼期望類型爲動物的類應該可以工作。這意味着動物不應該有一個叫做樹皮的方法，因爲cat類型的子類將無法吠叫。使用Animal類的類也不應該依賴於屬於類Dog的方法。不要做像「如果這隻動物是狗，然後（把動物對狗）樹皮，如果動物是貓然後（把動物對貓）喵喵叫」。
4. 接口隔離原理。保持您的界面儘可能最小。同樣是學生的老師應該實施IStudent和ITeacher接口，而不是稱爲IStudentAndTeacher的單個大接口。
5. 依賴倒置原理。對象不應該實例化它們的依賴關係，但它們應該傳遞給它們。例如，內部具有Engine對象的Car不應該執行engine = new DieselEngine（），而應該將引擎傳遞給構造函數。這樣汽車級別將不會與DieselEngine類相關聯。