问题标签 [open-closed-principle]

我对Command Design Pattern感到两难。Receiver 是一个知道如何执行操作的类的接口。

在链接中给出的示例案例中，接收器类Stock Trade知道如何执行 2 个操作，StockTrade#buy并且StockTrade#sell. 这些操作对应于 2 个现有命令BuyStockOrder和SellStockOrder.

但是，如果需要添加其他命令，例如FooStockOrderandBarStockOrder怎么办？然后，Receiver必须更改接口（以及所有现有实现），因此违反了开闭原则。

Receiver如何以（几乎）从未改变的方式解决这个问题？

我正在开发和维护一组 WCF 服务。该功能在服务中分组。支付内容在一个服务中，纯数据在另一个服务中，应用程序功能（主要是 CRUD）在第三个服务中。

大约每个发布周期，另一个团队都会从我们封闭的数据库中请求一些东西，因此我们在数据服务上添加了一个方法。

我们正试图摆脱我们前辈的糟糕编码（他们使用匈牙利符号和嵌套的 try/catch 而不是循环）并转向面向对象编程之类的东西。

Open/Closed 原则能否适用于用 WCF 编写的服务，而无需每次都编写新服务？值得花时间尝试吗？

谢谢。

我运行这个开源库，巧妙地命名为Unit Class Library。它的目的，像许多其他人一样，是允许更智能地处理单位（四舍五入，转换等）。这里是图书馆的一个例子

显然，*运算符在 Distance 类中被重载，如下所示：

在尝试在实际应用程序中使用该库时，我需要使用这些类型做一些复杂的方程，并且目前必须将我的所有单位减少回任意双精度数来进行数学运算：

假设我们正在计算体积流量

（这只是一个例子。由于积分和导数，我的实际应用程序中的方程以距离 ^ 5th 和其他奇怪的单位结束。）

这是一个令人不快的解决方案，因为它会导致不必要的转换。这引入了不必要的舍入误差。而且我知道我可以制作一个操作员来处理这个问题。

Tangent

如果您查看库的其余部分，您会发现从传入的值到不同单位的转换被延迟到需要它时。这确保了只要它与给定的单位相同，您将始终返回与输入相同的值。像这样：

end Tangent

我希望能够做到这一点：

无需编辑 Volume 类以包含新运算符。

我可以进入适当的位置并为每个新组合添加一个新的运算符，当它添加到库时应该返回 VolumetricFlowRate，但这很乏味并且违反了开放封闭原则。

有没有人提出一个解决方案的建议，该解决方案可以用每种新类型进行干净扩展，但又不违反开放封闭原则？

我知道开放封闭原则意味着开放扩展和封闭修改。考虑如下示例

现在我知道该类使用开放封闭原则Bike扩展并添加了新功能。Vehicle

考虑我创建类的 jar 文件，Vehicle然后Bike类从 jar 扩展Vehicle类。在这种情况下，我们不能修改Vehicle类并Bike扩展它。这是开闭原则的一个很好的例子吗？我想知道OCP与继承有何不同

我正在使用 C++ 开发一个具有图形用户界面的大型项目。用户界面将使用一些依赖于观察者模式的设计模式（MVVM/MVC）。

我的问题是我目前无法预测模型的哪些部分应该是可观察的。而且有很多很多部分。

由于这个问题，我发现自己被拉向了几个方向：

1. 如果我开发不支持通知的后端类，我会发现自己违反了 Open-Closed 原则。
2. 如果我确实为所有模型类及其所有数据成员提供通知支持，那么它将产生巨大的性能成本，这是不合理的，因为实际上只需要这种支持的一小部分（即使这部分是未知的）。
3. 如果我仅通过将所有非常量方法设为虚拟并通过基指针访问这些方法来提供对扩展的支持，情况也是如此。这也会以可读性为代价。

我觉得在这 3 个中，（1.）可能是较小的邪恶。

但是，我觉得理想的解决方案实际上应该存在于某种语言（绝对不是 C++）中，但我不知道它是否在任何地方都受支持。

我正在考虑的独角兽解决方案是这样的：给定一个数据类，寻求使数据可观察的客户不应该做类似的事情吗

@MakeObservable(数据)

作为编译时构造。这反过来又可以在 Data 对象上调用 addObserver 并使用通知器修改对数据成员的所有分配。它还会使您只为获得的性能付出代价。

所以我的问题有两个：

1. 我是否正确地假设在我所说的 3 个选项中，（1.）是较小但必要的邪恶？
2. 我的独角兽解决方案是否存在于任何地方？正在处理？还是由于某种原因无法实施？

首先，我知道这个问题以前在这里被问过，但对我来说并不清楚。

模式匹配用于使函数对不同类型的数据做出反应。有人会说，如果我的模式匹配案例有 4 个案例，而一个月后我需要添加第 5 个案例，我将违反开闭原则。我同意这一点。

在最坏的情况下：假设我正在使用一个封闭的库（我无法触摸其中的代码）并且我需要扩展它的功能。我想扩展的功能确实是模式匹配功能。我应该怎么办？

如果我完全确定我的对象不会经常更改并且永远不需要被其他人扩展，我认为模式匹配是可以的。

您对使用这种技术有何看法？这更像是一场辩论而不是一个问题。

谢谢，

“OCP Java SE 6 Programmer Practice Exams (Exam 310-065)”Assesment test 2 中的一个问题。

鉴于：

结果是什么？

A. c 1 c 1

B. c 1 c 2

抄送 1 1

D. 抄送 1 2

E. 抄送 2 2

F. 编译失败。

G. 运行时抛出异常。

书上的答案是 C。

但是当我尝试运行此代码时，我得到编译错误，说“静态字段 WeatherTest.Weather.RAINY 应该以静态方式访问”。

这是正确和预期的，但没有人在互联网上抱怨它，所以我想知道我是否遗漏了什么？它与Java版本有关吗？

我有一些这样的代码，将 Sting 转换为对象。但它在 for 循环中包含 if 语句，以指示第一个节点和最后一个节点。还有比这更好的编码吗？

我知道根据开闭原则，类，接口，代码......添加新功能或内容时应该保持不变，但文件也在这种情况下吗？

我在设计一个游戏，游戏有一些怪物信息，如果有新的怪物要添加或更新，游戏（在客户端）可能会下载或替换一些文件。

我在担心怪物信息的格式应该是什么：1个包含所有怪物信息的文件还是每个怪物都有单独的文件？

1.将所有怪物信息存储到一个文件中（例如：monsterlist.json），每次添加新怪物都会替换该文件，例如：

2.每个怪物都有一个单独的文件，每次添加一个新怪物也会添加一个新的怪物json：

怪物1.json

怪物2.json

一开始我认为case 1最方便，因为当我添加或更新任何怪物时，我只需要替换monsterlist.json，但是对于case 2，我需要知道哪个json是新的（可能需要额外的行来存储更新状态在服务器数据库中）。

但是突然想起开闭原则，添加新东西不应该修改当前内容，添加新怪物时替换文件似乎不合理。

以上只是我认为“文件”是否包含在开放封闭原则中的示例，而不是询问哪种格式更好。我要问的重点不是哪种文件格式更好，而是开闭原则的定义，因为我找不到任何提到“文件”的定义，一旦确定，我就可以推断出应该使用哪种文件格式。

作为一名将自己介绍给 C# 的 Java 程序员（初学者），我发现您可以重新抽象出一个已经实现的方法（来自此答案的代码）

我知道这不会使 D 类中的原始实现完全不可用，仅对通过子类化 E（重新抽象方法的类）将其子类化的 D 的子类不可用，因此不应导致任何实际如果 D 类正在生产中，则会出现问题。

不过，我发现自己想知道，这不是在修改 D 类的合同吗，它没有指定子类必须覆盖DoWork(int i)？这不违反开放/封闭原则吗？

请注意，我没有任何实际甚至理论上的代码被此破坏，请记住，我只是从 C# 开始，所以我可能会在这里遗漏一些东西。