呼吁从 SOLID 设计原则中移除“开闭原则”

OCP 或“开闭原则”是面向对象设计 SOLID 原则中流行的“O”。

作为在伦敦工作的架构顾问，我每次面试都会被问到关于 SOLID 的问题。 通常面试大约一个小时，我用一种超出课本范围的答案来回答这个问题，否则，面试将持续几个小时。 我把我的意见留给自己，我是一个更快乐的人。 :)

原则起源

首先，让我引用 OCP 的起源。 这首先由 Bertrand Meyer（Eiffel 的创建者）提到，然后在 2000 年由 Robert C. Martin（Bob 叔叔）在 原则和模式中提出。

引用 Martin 的论文

“一个模块应该对扩展开放，但对修改关闭。”

“在所有面向对象设计的原则中，这是最重要的。[...]。 它的意思很简单：我们应该编写我们的模块，以便它们可以被扩展，而不需要对它们进行修改。 换句话说，我们希望能够改变模块的功能，而无需改变模块的源代码。”

什么是模块？

模块可以是类、类组或组件，例如构成功能的库。 我将在下面的讨论中假设所有这些。

到处都是 Virtual

当我发布一个类的那一刻，我不应该改变它！ 我应该考虑它可以扩展的所有可能性，准备好我所有的作为虚函数的方法，放弃“从最简单可行的事情开始”的敏捷原则，并考虑完整的架构，现在！ 我将失去修改它的最后机会，我最好现在就行动，甚至在我检入之前，这是不归路，关闭开放的时刻，我的最后机会，哈哈哈哈！

为什么我们要编写单元测试？

如果每次我想遵循 OCP，在不改变现有实现的情况下，扩展我的模块，那么我实际上不必编写面向未来的代码，因为代码不会改变，每次我都会扩展现有代码，并且作为软件变更的规范，我会不断扩展，并且我会达到数百个继承类链。 我可以少写一些单元测试，因为这个模块的逻辑不会改变！

但是“优先使用组合而不是继承”发生了什么？

这是否与 OCP 相矛盾？ 现在，每次我想改变，我都会用另一个类包装我的现有类（有点像装饰器GoF设计模式），然后原始实现将被 10 个类覆盖，并且无法访问。

认真地说，让我们删除它

也许这个原则在瀑布时代有效，或者它可能，我使用了“可能”这个词，在第三方组件或框架中有效，但它在日常业务开发中不起作用。

结论

我们习惯于传播这个术语，不再称其为原则，而没有经过太多考虑。 下次面试官问我关于 SOLID 原则的问题时，我会问他/她，你是说 SLID 吗？

我在发布之前审查了这个，语气听起来像我在咆哮，但事实是，我在笑并享受它。 我希望你和我分享类似的喜悦。