这是对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替换就是要确保从接口/基类继承的对象的行为与接口/基类承诺的行为方式一致。在对原始定义进行最严格的解释时，他们需要表现得完全一样，但这并不是那么有用。更一般地讲，它的行为以一致和预期的方式进行，派生类可以添加功能，但是它们应该能够完成基础对象的工作（它们可以替代它们）