问“开放/封闭原则”与“依赖反转原则”有什么区别？

EN

我觉得关于依赖注入和开放/封闭的解释也令人困惑。不一定是那样的。让我们看一看您引用的文章：http://www.oodesign.com/open-close-principle.html

在他们的示例中，有一个GraphicsEditor类和一个形状类的层次结构。在他们显示的第一类图中，GraphicsEditor中有一组用于绘制各种形状类的方法: drawShape；drawCircle；drawRectangle。

当你想要添加一个平行四边形类时会发生什么？首先创建新的类参数四边形，然后修改GraphicsEditor类以添加一个名为drawParallelogram的新方法。

这就是本文提到的“坏”：添加一个新的形状意味着您必须更改现有代码。您添加了一个新的形状子类(参数化四边形)，并向GraphicsEditor (drawParallelogram)添加了一个新方法。

这看起来并不是什么大问题，但它并没有扩大规模。想象一下，一个由20名开发人员组成的团队，所有开发人员都同时在开发该软件。首先，每个添加新形状的开发人员都必须记住做两件事:更新退出代码和创建新代码。加入这个项目的每一个新开发人员可能都会很难学到这一点。第二，如果每个人每天都添加新的形状，这意味着每个人都在尝试编辑GraphicsEditor类。在同一时间。是头痛。问我怎么知道的。-)(在修改现有代码时，也有可能在现有代码中引入bug。)

如果您可以在不接触GraphicsEditor类的任何代码的情况下向系统添加一个新的形状，这将是非常理想的。这就是这篇文章想要展示的。

查看本文中的第二类图表。每个形状现在都实现了自己的绘制方法。GraphicsEditor只需要知道有一些超类，即"Shape"，并且它的所有子类都实现了“绘图”方法。GraphicsEditor不再关心有多少子类或它们的名称。开发人员可以自由地实现新的形状，而不必修改GraphicsEditor类。GraphicsEditor类现在“关闭”了。以这种方式，系统是“开放的扩展”-没有现有的代码必须改变，以创建新的形状。问题解决了。

了解所有这些的一个更简单的方法是学习访问者设计模式。我不喜欢维基百科对这种模式的解释，所以我将指出另一个地方：http://sourcemaking.com/design_patterns/visitor。我认为理解访问者模式会使所有其他的术语和概念变得合适。