澄清开放/封闭原则

Question

正如我已经解释过的，开放/封闭原则规定，一旦编写了代码，就不应该修改(除了bug修复之外)。但是，如果我的业务规则发生了变化，难道我不应该修改实现这些更改的代码吗？我怀疑我对这个原则不太了解，因为这对我来说毫无意义。

Answer 1

这可能是最难解释的坚实原则。让我试一试。假设您编写了一个运行良好且没有bug的发票类。它是发票的PDF格式。

然后有人说，他们想要一个带有链接的HTML发票。您不需要更改发票中的任何代码以满足此要求。相反，您可以创建另一个类，HTMLInvoice，它实现了他们现在想要的结果。您可以利用继承，这样就不必在HTMLInvoice中编写大量重复的代码。

使用旧发票的旧代码不会被破坏，也不会受到任何影响。新代码可以使用HTMLInvoice。(如果您还做了Liskov可替换性 ( solid的L)，您可以将HTMLInvoice实例提供给期望发票实例的现有代码。)从此以后，每个人都过着幸福的生活。

发票不允许修改，可以延期。而且你必须事先写好发票，这样才能起作用。

Answer 2

凯特·格雷戈里(凯特·格雷戈里)回答非常好，但是考虑另一种情况，即新的需求可以通过现有Invoice类中相对较小的更改来满足。例如，假设必须在发票PDF中添加一个新字段。根据OCP，我们仍然应该创建一个新的子类，即使可以通过更改几行代码将新字段添加到现有的实现中。

据我所知，OCP反映了80's和90年代早期S的现实，在那里，项目往往甚至不使用版本控制，更不用说自动回归测试或复杂重构工具的好处了。OCP是为了避免破坏已经手工测试并投入生产的代码的风险。今天，我们有了更好的方法来管理中断工作软件的风险(即版本控制系统、TDD和自动化测试以及重构工具)。

Answer 3

就我个人而言，我认为这个原则应该是一小撮盐。代码是有机的，随着时间的推移，企业的变化和代码的变化取决于企业的需要。

我发现很难理解抽象是关键这一事实。如果抽象最初是错误的呢？如果业务功能发生了重大变化怎么办？

这一原则在本质上确保了设计的初衷和行为永远不会改变。这可能适用于那些拥有公共API的人，他们的客户很难跟上新版本和其他一些边缘情况。然而，如果一家公司拥有所有的代码，那么我就质疑这个原则。

对代码进行良好的测试覆盖会使重构您的代码库变得轻而易举。这意味着错误的东西是没有问题的-你的测试将帮助你找到一个更好的设计。

如果没有测试，那么这个原则是正确的。