当业务逻辑发生变化时，如何尊重开放封闭原则？

Question

我们正在对我们的系统进行一些重大更改，我想知道实现这些新业务逻辑规则的最佳方法，尊重 SOLID 原则：

开放/封闭原则说“开放用于扩展，但关闭用于修改”好吧，但是如何我可以修改吗？我的意思是，我不想保留旧的业务逻辑，在我看来“扩展”主要意味着“添加代码”而不是“更改代码”，那么我理解错了什么？

Answer 1

Open/Closed 背后的想法是，如果您需要不同的业务逻辑，则需要创建一个新的业务逻辑类。

然而，这样做的主要动机是您不想影响现有的代码、重新测试、再次签核等。如果您使用的业务逻辑发生了根本性的变化，那么您将更改对的所有引用一个新对象并废弃旧对象，在这种情况下重新打开对象进行修改是可以接受的。关键是（1）无论如何你都需要重新测试所有代码，（2）旧对象不会在任何地方使用。

哈特哈，
詹姆斯

Answer 2

两个大问题：

我们在这里谈论什么样的变化？

您有什么样的现有代码？它是否已经符合任何 SOLID 原则？

假设我们需要对设计良好的现有应用程序进行一些更改。也许考虑一下工资单应用程序。我们可能有一个Interafce（这只是一个人为的示例）

 public Interface EmployeeContract {         
      public int computeSalaryForMonth(int month);
 }

并且我们有实现：

 public class SalesContract implements EmployeeContract {
      public int computeSalaryForMonth(int month){
               // computation involving sales figures and base salary
      }
 }

  public class HourlyContract implements EmployeeContract {
      public int computeSalaryForMonth(int month){
               // computation involving hours worked and overtime payments
      }
 }

现在应用程序的所有其他部分都是根据接口进行编码的。

我们现在可以添加新类型的合约，而无需更改任何现有代码，我们愿意进行扩展并添加可能相当复杂的新业务逻辑。

但是那是因为最初的设计师预料到了这种变化，添加了新的每月合同类型。如果我们想雇用每周领取工资的员工，那不是很好吗？现在我们的界面不合适，我们需要改变它，并且效果会波及其他代码。

实际上，软件不会对任意业务逻辑的轻松更改开放，并且实际上尝试预先实现灵活性需要花费大量精力。但是请注意，即使在我的示例中，接口并不像我们现在需要的那么灵活，因为接口是耦合点，所以很容易识别需要更改的代码部分。

摘要：根据您的情况：

1. 了解现有代码的结构以及它的灵活性点。接受某些代码需要更改的事实，并且业务中的重大更改可能需要对代码进行重大更改也就不足为奇了。
2. 结构通常有助于可维护性，因此在添加新代码时要注意结构。通过对接口进行编码，在代码中提供“防火墙”，在完成工作和开放扩展之间取得平衡。

Answer 3

开放-封闭原则意味着您不必更改当前的代码，因此它对于修改是关闭的，但为了满足新的需求，您需要使用子类、实现接口、设计模式来扩展代码，以便您的代码对此活动是开放的。当然，在重构时你会面临需要更改代码的情况，但你必须以某种方式来满足 OSP。

例如，您可以创建工厂方法，而不是创建分散在代码中的类似对象的新实例。当新的需求添加一个新对象时，您的代码将关闭以进行修改（代码中没有新实例），但将打开以进行扩展（扩展工厂方法）。