开闭原则是个好主意吗？

Question

这个问题不是关于什么是OCP。我也不是在寻找简单化的答案。

所以，这就是我问这个的原因。 OCP 首次描述于 80 年代末。它反映了当时的思想和背景。人们担心的是，在代码经过测试并投入生产后，更改源代码以添加或修改功能，最终风险太大且成本高昂。因此，我们的想法是尽可能避免更改现有源文件，而仅以子类（扩展）的形式添加到代码库中。

我可能是错的，但我的印象是基于网络的版本控制系统（VCS）当时并未得到广泛使用。关键是 VCS 对于管理源代码更改至关重要。

重构的想法是最近才出现的。在当时，支持自动化重构操作的复杂 IDE 肯定是不存在的。即使在今天，许多开发人员也没有使用最好的重构工具。这里的要点是，这种现代工具允许开发人员在几秒钟内安全地更改数千行代码。

最后，如今自动化开发人员测试（单元/集成测试）的想法已经很普遍。有许多免费且复杂的工具支持它。但是，如果我们从不/很少更改现有代码，那么创建和维护大型自动化测试套件有什么好处呢？按照 OCP 的要求，新代码只需要新的测试。

那么，OCP 在今天真的有意义吗？我不这么认为。相反，如果新功能不需要新类，我确实更愿意在添加新功能时更改现有代码。这样做将使代码库更简单、更小，并且更容易阅读和理解。破坏先前功能的风险将通过 VCS、重构工具和自动化测试套件进行管理。

Answer 1

当您不是代码的使用者时，OCP 就很有意义。如果我正在编写一个类，并且我或我的团队正在编写使用该类的所有类，我同意。随着事物的变化进行重构根本不是什么大事。

另一方面，如果我正在为我的客户编写 API，或者我在一个大型组织中有多个具有不同兴趣的消费者，那么 OCP 就至关重要，因为我无法轻松重构。

另外，如果您只是重构您的类来满足每个人的需求，您将得到一个臃肿的类。如果您设计的类允许使用者扩展您的类而不是修改它，那么您就不会真正遇到此问题。

Answer 2

我从来没有听说过 OCP 是这样的。也许您指的是其他东西，但我知道的 OCP 说“模块/类必须对扩展开放，但对修改关闭，这意味着您不应该修改模块的源代码以增强它，但模块或对象应该易于扩展，

例如 eclipse（或任何其他基于插件的软件）。您没有源代码，但任何人都可以编写。一个插件来扩展行为或添加另一个功能。您没有修改 eclipse，但您扩展了它。

所以，是的，开放/关闭原则确实非常有效并且是一个好主意

更新：

我看到了主要内容 。这里的冲突是仍在开发的代码和已经被某人发布和使用的代码之间的，所以我去检查了 Bertrand Meyer，该原则的作者，他说：

如果一个模块可供其他模块使用，则称该模块已关闭。 这假设
该模块已被赋予明确定义的、稳定的描述（其接口在
信息隐藏意识）。在实现级别，模块的闭包也
意味着您可以编译它，也许将其存储在库中，并使其可用
供其他人（其客户）使用。

因此，事实上，开放/封闭原则仅指稳定的、可供编译和使用的实体。

Answer 3

好吧，这就是我的回应。

我无法证实这一原则的历史渊源，但它在现代仍然被频繁引用。我不认为更改功能代码是危险的（尽管当然是危险的），而是允许您分离出想法。

假设我们有一个组件，

public class KnownFriendsFilter{
  IList<People> _friends;
  public KnownFriendsFilter(IList<People> friends) {
    _friends = friends;
  }
  public IList<Person> GetFriends(IList<Person> people) {
    return people.Where(p=>_friends.Contains(p)).ToList();
  }
}

现在说这个特定组件需要稍微修改的算法 - 例如，您想确保传入的初始列表包含不同的人。这是 KnownFriendsFilter 所关心的问题，因此请务必更改该类。

但是，此类与其支持的功能之间存在差异。

• 这个类实际上只是过滤一组人中已知的朋友。
• 它支持的功能是从一组人中查找所有朋友。

不同之处在于，功能涉及功能，而类涉及实现。我们更改该功能的大多数请求都超出了班级的具体职责。

例如，假设我们要添加任何以字母“X”开头的名字的黑名单（因为这些人显然是太空人，而不是我们的朋友）。这是支持该功能的东西，但实际上并不是这个类的全部内容的一部分，将它放在类中会很尴尬。当下一个请求出现时，现在该应用程序仅由厌恶女性的人使用，并且任何女性名字也必须被排除在外，该怎么办？现在你必须添加逻辑来决定班级中的名字是男性还是女性 - 或者至少知道其他一些知道如何做到这一点的班级 - 班级的责任越来越大并且变得非常臃肿！那么跨领域的关注点又如何呢？现在，每当我们过滤一组人时，我们都想记录下来，这也可以记录下来吗？

最好分解出 IFriendsFilter 接口并将此类包装在装饰器中，或者将其重新实现为 IList 上的责任链。这样，您就可以将每个职责放入自己的类中，以支持该关注点。如果您注入依赖项，那么任何使用此类（及其在我们的应用程序中集中使用）的代码都无需更改！

再说一次，这个原则并不是永远不改变现有的代码，而是不要最终面临这样的情况：是让常用类的职责变得臃肿，还是必须编辑使用它的每个位置。

Answer 4

那么，OCP 在今天真的有意义吗？我不这么认为。

有时确实如此：

• 当您向客户发布了基类并且无法在所有客户的计算机上轻松修改它时（例如，参见“DLL Hell”）

• 当您是客户时，您自己没有编写基类，也不是那个客户维护它

• 更一般地说，基类被多个团队使用的任何情况，并且/或用于多个项目

另请参阅康威定律。

Answer 5

有趣的问题，基于开闭原则的严格定义，我可以看到你来自哪里。

我对开闭原则的定义略有不同，我认为这个原则应该适用，那就是更广泛地应用它。

我想说，应用程序中涉及的所有类（作为一个整体）都应该关闭以进行修改并开放以进行扩展。因此，原则是，如果我需要更改应用程序的行为和/或操作，我实际上不会修改类，而是添加一个新类，然后更改关系以指向这个新类（当然取决于大小）的变化）。如果我遵循单一责任并利用控制反转，这种情况应该会发生。然后发生的事情是所有的改变都变成了扩展。他们的系统现在既可以以以前的方式运行，也可以以新的方式运行，并且它们之间的改变=改变关系。

Answer 6

这里的要点是，这种现代工具允许开发人员在几秒钟内安全地更改数千行代码。

如果您有“一名”开发人员，那就很好。如果您在团队中工作，当然需要版本控制，可能需要分支和合并，那么确保不同人的更改最终集中在不同文件中的能力对于能够控制正在发生的事情非常重要。

您可以想象特定于语言的合并/分支工具可以并行完成三个重构，并像更改独立文件一样轻松地合并它们。但这样的工具并不存在，如果存在，我也不想依赖它们。