“开放/封闭原则”和“开放/封闭原则”有什么区别?和“依赖倒置原则”?

发布于 2024-12-18 19:26:46 字数 190 浏览 3 评论 0原文

我读过有关 SOLID 的文章,但我没有看到 OCP 和 DIP 之间有任何区别。看一下 OCP 的示例:

http://www.oodesign.com/open-close-principle.html

保存 OCP 的代码也满足 DIP。谁能给我一个包含 OCP 而不是 DIP 的代码示例?

I read articles about S.O.L.I.D. but I don't see any difference between OCP and DIP. Look at this example of OCP:

http://www.oodesign.com/open-close-principle.html

The code which holds OCP also fulfils the DIP. Can anyone give me an example of code that holds OCP and not DIP?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

雾里花 2024-12-25 19:26:46

我发现依赖注入和打开/关闭的解释也很令人困惑。事情并不一定是这样的。让我们看一下您引用的文章: http://www.oodesign.com/open-close-principle.html

在他们的示例中,有一个 GraphicsEditor 类和一个形状类层次结构。在他们展示的第一个类图中,GraphicsEditor中有一堆方法用于绘制每种形状类:drawShape;画圆;绘制矩形。

当您想添加 Parallelogram 类时会发生什么?首先创建新类 Parallelogram,然后修改 GraphicsEditor 类以添加一个名为 drawParallelogram 的新方法。

这就是本文提到的“坏处”:添加一个新形状意味着您必须更改现有代码。您添加了 Shape (Parallelogram) 的新子类,并向 GraphicsEditor (drawParallelogram) 添加了新方法。

这可能看起来没什么大不了的,但它无法扩展。想象一下一个由 20 名开发人员组成的团队同时致力于该软件。首先,每个添加新形状的开发人员都必须记住做两件事:更新现有代码并创建新代码。每个加入该项目的新开发人员可能都会经历惨痛的教训才明白这一点。其次,如果每个人每天都添加新形状,则意味着每个人都在尝试编辑 GraphicsEditor 类。同时。很头疼。问我怎么知道的。 :-)(修改现有代码时也有可能引入错误。)

如果您可以向系统添加新的 Shape 而无需触及 GraphicsEditor 类中的任何代码,那将是理想的选择。这就是本文想要论证的。

看文章中的第二个类图。每个形状现在都实现自己的绘制方法。 GraphicsEditor只需要知道有一个超类“Shape”,并且它的所有子类都实现了“draw”方法。 GraphicsEditor 不再关心有多少子类或者它们的名称是什么。开发人员可以自由地实现新形状,而无需修改 GraphicsEditor 类。 GraphicsEditor 类现已“关闭”。通过这种方式,系统是“可扩展的”——无需更改现有代码即可创建新形状。问题解决了。

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

I find the explanations of dependency injection and open/closed to be confusing as well. It doesn't have to be that way. Let's take a look at the article you reference: http://www.oodesign.com/open-close-principle.html

In their example, a there is a GraphicsEditor class and a hierarchy of shape classes. In the first class diagram they show, there are a bunch of methods in the GraphicsEditor for drawing each kind of shape class: drawShape; drawCircle; drawRectangle.

What happens when you want to add a Parallelogram class? You first create the new class Parallelogram and then you modify the the GraphicsEditor class to add a new method called drawParallelogram.

This is the "badness" the article refers to: adding one new shapes means you have to change existing code. You add a new subclass of Shape (Parallelogram) and you add a new method to GraphicsEditor (drawParallelogram).

That might not seem like a big deal, but it does not scale. Imagine a team of 20 developers all working on the software at once. First, every developer that adds a new shape has to remember to do two things: updated exiting code and create new code. Every new developer that joins the project will probably learn this the hard way. Second, if everyone is adding new shapes every day, it means everyone is trying to edit the GraphicsEditor class. At the same time. It's a headache. Ask me how I know that. :-) (There is also a chance of introducing a bug into existing code when it is modified.)

It would be ideal if you could add a new Shape to the system without touching ANY code in the GraphicsEditor class. That is what the article wants to demonstrate.

Look at the second class diagram in the article. Each shape now implements its own draw method. The GraphicsEditor only needs to know that there is some superclass, "Shape", and that all of its subclasses implement the method "draw". The GraphicsEditor no longer cares how many subclasses there are or what their names are. Developers are free to implement new shapes without having to modify the GraphicsEditor class. The GraphicsEditor class is now "closed". In this way, the system is "open to extension"-- no existing code has to be changed to create new shapes. Problem solved.

A simpler way to understand all of this is to learn the Visitor Design Pattern. I don't like Wikipedia's explanation of this pattern, so I will point you to another place: http://sourcemaking.com/design_patterns/visitor. I think that understanding the Visitor Pattern makes all the other terms and concepts fall into place.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文