问题标签 [open-closed-principle]

我有一个类层次结构，负责将一个模型（或消息）解析或映射到另一个。它具有非平凡的逻辑。

这些具体的解析器有 21 个：

我想添加一个新的私有方法OriginalToConcreteMessageParser并在Serialize(). 让我们调用这个方法Baz()。

我可以创建OriginalToConcreteBazMessageParser并使所有 21 个具体实现都继承自此，但我不希望这样做。

提供的功能Baz()绝对是在OriginalToConcreteMessageParser.

总之，我想注入一个方法并在不接触的情况下OriginalToConcreteMessageParser调用它。Serialize()OriginalToConcreteMessageParser

我想重构以下代码以避免 if...else 这样我就不必在每次新的调查类型出现时都更改方法（打开/关闭原则）。以下是我正在考虑重构的一段代码：

为了解决这个问题，我添加了以下类：

这就是我的代码的最终结果：

我的问题是避免将 param2 和 param3 传递给 InvitationalSurvey 和 ReturnLaterSurvey 类有什么好处？

我目前正在为我正在设计的服务实现命令处理程序模式，其中命令本质上是处理程序.Handle()方法的 DTO。当我开始实现各种具体的类时，我意识到为了满足开放/封闭原则和单一职责原则，我最终可能会得到数千个 Command 和 Handler 类，这将严重违反 Don't Repeat Yourself 原则。

例如，我封装的部分过程需要ProjectId从 60 个奇数表中删除所有数据以重置它们。如果我将每个类都实现为原子具体的 Command 对象和具体的 CommandHandler 对象，那么我将有 120 个类仅用于第一步。 他们都将完全遵循 SRP 和 OCP，但是 DRY 受到严重打击......

或者，我可以实现一个单一的、多用途的命令和处理程序类，并且ProjectTables可以使用枚举来代替所有离散类。

然而，这将违反开放/封闭原则，因为如果添加新表，则枚举和使用它的每个地方都必须更新。更不用说你从 60 例 switch 语句中得到的气味了。

苏……谁赢了？DRY 还是 SRP 和 OCP？

我刚刚在我的一个类中创建了以下方法

我的一个朋友在查看我的代码时说，我不应该创建“扩展 List 类”的方法，因为这违反了开放/封闭原则。如果我想扩展 List 类，我应该创建一个继承自 List 的新类，并在该新类中实现我的“合并”方法。他是对的吗？扩展 List 类违反了 Open/Closed 原则？

因此，当编写原始代码时，只需要说 LabTest 类。但现在说我们有新的要求要添加，比如 RadiologyTest、EKGTest 等。

这些类有很多共同点，因此有一个基类是有意义的。

但这意味着 LabTest 类将不得不被修改，可以说它的界面将保持与以前相同，换句话说 LabTest 类的消费者将不需要更改。

这是否违反了开放封闭原则原则？（LabTest 正在修改）。

在下面的代码中，MessageProcessor该类违反了 Open Closed 原则 - 每个新的 IMessage 实现都需要对此类进行更改。对于这种不违反 O/C 的场景，是否有一个很好的干净模式？

我有一个像这样的数据构造函数

这样我就可以使用模式匹配：

然而，这打破了开/关原则。
我希望能够FooBar使用基于其他类的其他方法进行扩展。

我将如何在 Haskell 中实现这一点？

我正在为一家公司开发游戏。我只会开发这个游戏两个月。我的公司要求我使我的代码干净且可扩展，以便他们在需要添加更多功能时可以聘请其他程序员。我读过 Bob 叔叔的 Clean Code。我发现很难将一些概念付诸实践。这是我的一门课

}

我的问题是这个类是否违反了单一责任原则？我需要将每个演员分开到自己的班级吗？如果是这样，我应该如何重构我的代码？

正在阅读 SOLID 设计的 Open/Closed 原则，并对它的可维护性感到好奇。

假设我有从父类 A 继承的子类 B 和 C。B 具有 B 独有的方法，C 具有 C 独有的方法。父类 A 有两个子类使用的常用方法。

在未来的代码版本中，假设我们有一个新特性，它在 B 类和 C 类之间引入了一个公共方法。我们现在不能将该方法推到 A 类，因为它违反了原则的“关闭以供修改”部分。这似乎引入了代码冗余。不仅如此，从技术上讲，在B类和C类中增加这个新特性，是不是也违反了修改原则？

似乎使用 Open/Closed 方法，您最终会构建一个不必要的、级联的子类层次结构，仅仅是因为不允许对原始代码进行更改。这是一个正确的假设/理解吗？

下面的 ProductService 类从数据库中获取基于不同过滤器（例如按日期、国家/地区等）的产品。ProductsService 不遵循 OCP，因为添加新过滤器（如按价格获取产品）需要更改 ProductsService 代码。如何修复？任何建议/意见都会非常有帮助。