这是对SOLID面向对象原则的正确理解吗？

Question

在几个地方阅读SOLID之后，我在使用不同词汇和代码的解释之间进行映射时遇到了问题。为了概括一点，我创建了下面的图表，我希望人们可以指出任何错误＆＃39;在我的理解中。

当然，您可以随意重复使用/重新混合/重新分发！

Answer 1

我认为你的图表看起来很不错，但我担心我无法理解它们（尤其是界面），所以我会对文本发表评论。

我不清楚你的意思是什么层，在开放/关闭中我认为你可能意味着界面，但界面和依赖项暗示你并不意味着。

打开/关闭：实际上Liskov项目中的文本更接近于描述打开/关闭。如果代码是开放的扩展，我们可以利用它（通过扩展它）来实现新的需求，但是不修改现有的代码（它关闭以进行修改）我们知道我们不会破坏使用它的任何现有代码

“仅依赖于外层” - 如果这意味着只依赖于接口而不是实现，那么是的，这是SOLID代码的一个重要原则，即使它不直接映射到5个字母中的任何一个。

依赖性倒置使用了它，但超越了它。一段代码可以通过其接口使用另一段代码，这比依赖于实现具有很好的可维护性优势，但是如果调用代码仍然负责创建实现接口的对象（因此选择类），那么它仍然具有依赖性。如果我们在类或方法之外创建具体对象并将其作为接口传递，则被调用的代码不再依赖于具体类，只是依赖于接口

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更好的名字这可能是一个标志，它有多个责任，如果它是分裂可能会更好（我正在做的点是关于“和”in甚至当“事情”被更好地命名时，这个名字。） 您应该尝试定义该职责，以便该类可以完全执行它（尽管它可以使用其他执行子职责的类）但是在每个职责级别定义一个类时，它应该有一个明确的原因存在。当它有多个时，它可以使代码更难理解，并且与一个责任相关的代码的更改可能会对其他职责产生不必要的副作用。

Iterface segregation：考虑实现集合的类。该类将实现代码以添加到集合或从中读取。我们可以将所有这些放在一个接口中，但是如果我们将它分开，那么当我们消耗只需要读取的代码并且不需要添加到集合时，它就可以使用由读取方法构成的接口。这可以使代码更清晰，因为它快速显示代码只需要那些方法，并且，如果我们通过接口注入集合，我们也可以使用具有不同源项目的代码添加项目 （考虑IEnumerable vs ICollection vs IList）

Liskov替换就是要确保从接口/基类继承的对象的行为方式与接口/基类承诺的行为方式相同。在对原始定义的最严格解释中，他们需要表现得完全相同，但这并不是那么有用。更一般地说，它关于以一致和预期的方式运行，派生类可以添加功能，但它们应该能够完成基础对象的工作（它们可以替代它们）