3

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

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

4

3 回答 3

2

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

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

HTH，詹姆斯

于 2010-08-24T15:47:18.593 回答
1

两个大问题：

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

你有什么样的现有代码？它是否已经符合任何 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. 结构通常有助于可维护性，因此在添加新代码时请注意结构。通过对接口进行编码在代码中提供“防火墙”，在完成工作和对扩展开放之间取得平衡。
于 2010-08-24T15:44:08.957 回答
0

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

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

于 2010-08-24T15:43:54.887 回答