這是對SOLID面向對象原則的正確理解嗎？

Question

在幾個地方閱讀了關於SOLID之後，我在使用不同詞彙表和代碼的解釋之間進行映射時遇到了麻煩。概括一下，我創建了下面的圖表，我希望人們能夠根據我的理解指出任何「錯誤」。

當然，隨意隨意重用/混音/重新分配，只要你願意！

Answer 1

我覺得你的圖看起來很不錯，但我怕我不明白他們（特別是接口一個），所以我會在文本註釋。

我不清楚你的意思是什麼，在開放/關閉我以爲你可能意味着接口，但接口和依賴項意味着你不是這個意思。

打開/關閉：實際上，Liskov項目中的文本更接近於描述打開/關閉。如果代碼是可擴展的，我們可以利用它（通過擴展它）來實現新的需求，但是通過不修改現有的代碼（它是關閉的以進行修改），我們知道我們不會破壞任何使用它的現有代碼。

「只依賴外層」 - 如果這意味着只依賴於接口而不是實現，那麼是的，即使它不直接映射到5個字母中的任何一個，對於SOLID代碼來說，這是一個重要的原則。

依賴反轉使用，但超越它。一段代碼可以通過其接口使用另一段代碼，這相對於依賴實現具有很大的可維護性優點，但是如果調用代碼仍然負責創建實現接口的對象（並因此選擇類），那麼它仍然有依賴性。如果我們創建的類或方法，並把它作爲一個接口外的具體對象，然後調用的代碼不再依賴於具體的類，只是接口

void SomeFunction() 
{ 
    IThing myIthing* = new ConcreteThing(); 
    // code below can use the interface but this function depends on the Concrete class   
} 

void SomeFunctionDependencyInjectedVersion(IThing myIthing*) 
{ 
    // this version should be able to work with any class that implements the IThing interface, 
    // whether it really can might depend on some of the other SOLID principles 
} 

單一職責：這是不是類相交，這是關於不給一個以上的代碼責任。如果你有一個功能，你不能想到比doSomethingAndSomethingElse更好的名字，這可能是一個跡象，它有多個責任，如果它被分割，它可能會更好（我要說的是關於「和」這個名字即使在「有些事情」更好的情況下也是如此）。
您應該嘗試定義責任，以便類可以完全執行它（儘管它可以使用其他類來執行其子類責任），但是在定義類的每個責任級別上，它應該有一個明確理由存在。當它有多個代碼時，它可能使代碼更難理解，而對與一個責任相關的代碼的更改會對其他責任產生不必要的副作用。

Iterface分離：考慮實現集合的類。該類將實現代碼添加到集合或從中讀取。我們可以將所有這些放在一個接口中，但是如果我們將它分開，那麼當我們消費的代碼只需要讀取並且不需要添加到集合中時，它就可以使用由讀取方法組成的接口。這可以使代碼更清晰，因爲它很快顯示代碼只需要這些方法，並且如果我們已經通過接口注入了集合，我們也可以使用該代碼以及不具有添加項目 （考慮IEnumerable vs ICollection vs IList）

Liskov替換就是要確保從接口/基類繼承的對象的行爲與接口/基類承諾的行爲方式一致。在對原始定義進行最嚴格的解釋時，他們需要表現得完全一樣，但這並不是那麼有用。更一般地講，它的行爲以一致和預期的方式進行，派生類可以添加功能，但是它們應該能夠完成基礎對象的工作（它們可以替代它們）