开闭原则OCP与KISS简单原则冲突吗？

如何看待开闭原则（OCP）？ 有些人不认同OCP，他们认为我们应该专注于编写简单的代码。 我同意这一点，但是我看不到简单性和OCP是如何不兼容的。

有两个初步要点：

1. OCP的目标不是编写我们再也不会修改的关闭代码，否则将导致过度设计和前端大设计（BDUF）。 我们将用无用的抽象来填充代码，以解决不存在的问题。
2. 完全遵守OCP是不可能的。 无法通过添加新代码而不修改现有代码来满足用户要求的任何可能的更改。 我们无法预见用户将要求的每一项变更。

考虑到这些要点，编写简单的代码非常有道理。 当用户要求更改时，简单的代码将使我们能够轻松地应用更改。 而且，如果我们得到用户的频繁反馈的情况下。

我们将知道用户所需的更改，并且我们将能够创建使这些更改的应用变得更加容易的抽象。编写简单的代码，重构和添加抽象，因为它们被证明是必要的。注意YANGNI原则。

下面是您遵守OCP的方式：

• 在实际用户需求的驱动下，OCP从重构中浮现出来。
• OCP并非来自BDUF设计人员的预期行为。

OCP的要点是：

• 抽象化：将抽象与底层细节分开；
• 将变化与保持不变分开。

OCP是否仍然有意义？ 我会说是的。 如果您编写了一个将模块发送文本到设备的抽象模块，那么在不接触模块的情况下添加新类是否很好？ 这就是我们实现可扩展模块和可插入行为的方式。

banq注：当需求改变或增加时，有两种直觉：需求改变，就要修改原有代码；需求新增加功能，就要新增代码：

需求有两种变化：新增和修改。

代码有两种变化：新增和修改。

这两种不一定要一一对应，而是根据简单原则和OCP原则去选择代码的新增或修改来满足需求的新增，使用代码的新增或修改来满足需求的修改。

简单原则是当下工作的简单，OCP原则是为了让代码结构简单。这两者都需要考虑。

编程第一法则：如果它工作，就不要碰它