软件设计原则之开闭原则

本文主要是介绍软件设计原则之开闭原则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

开闭原则（Open-Closed Principle, OCP）是软件设计中的一个重要原则，由伯特兰·梅耶（Bertrand Meyer）在1988年提出。该原则强调软件实体（如类、模块、函数等）应该对扩展开放，对修改关闭。这意味着当软件需要变化时，我们应该通过扩展已有软件实体的功能来实现新的需求，而不是通过修改已有代码来完成。以下是开闭原则的详细解析：

开闭原则的定义

扩展开放：软件实体应该能够通过增加新的模块或功能来扩展其行为，而不需要修改现有的代码。
修改关闭：软件实体一旦被创建并投入使用，其内部实现应该保持稳定，不应轻易修改。

开闭原则的好处

提高软件的可维护性：通过减少修改现有代码的需求，降低了因修改引入错误的风险，使得软件更加稳定可靠。
增强软件的可扩展性：允许在不改变现有代码结构的情况下添加新功能，使得软件能够更灵活地应对未来需求的变化。
促进软件复用：遵循开闭原则设计的软件模块往往具有更高的独立性和可复用性，可以在不同的项目中重用。

开闭原则的实现策略

使用抽象和接口： 通过定义抽象类或接口来规定软件实体的行为，使得具体的实现类可以独立地变化而不会影响其他部分。
策略模式： 将一系列算法封装在独立的策略类中，并使它们可以相互替换。这样，算法的变化不会影响到使用算法的客户。
模板方法模式： 在父类中定义一个算法的框架，将某些步骤的实现延迟到子类中。这样，既可以在不修改父类代码的情况下扩展算法，又可以保持算法的结构清晰。

“开闭原则”的比方

排插是这一原理的一个很好的例子。
在这里插入图片描述
插头总是关闭的修改，一旦安装或扩展就不能进行修改，但是排插总是提供一种扩展方法，因此我们可以插入排插来获取更多的适配。

不遵循开闭原则的示例

银行提供各种类型的储蓄帐户(工资储蓄，定期储蓄等) ，以满足不同类型的客户的需要。银行有不同的规则集，每种储蓄账户类型都有不同的计算利息的规则集。
为了计算账户的利息，开发人员开发了以下类，并使用了计算利息的方法。

Public class SavingAccount  
{  //Other method and property and code  Public decimal CalculateInterest(AccountType accountType)  {  If(AccountType=="Regular")  {  //Calculate interest for regular saving account based on rules and   // regulation of bank  Interest = balance * 0.4;  If(balance < 1000) interest -= balance * 0.2;  If(balance < 50000) interest += amount * 0.4;  }  else if(AccountType=="Salary")  {  //Calculate interest for saving account based on rules and regulation of   //bank  Interest = balance * 0.5;  }  }  
}

在上述代码中，SavingAccount 类的 CalculateInterest 方法根据类似 Salary 和 Rules 的帐户类型进行计算。
这个实现并没有遵循开放关闭原则，因为如果明天银行引入了一个新的 SavingAccount 类型，那么就需要修改这个方法来为新的帐户类型添加一个新的用例。
例如，如果银行引入“子女储蓄帐户类型”，要求在计算该帐户类型的利息时附加一个新条件。这意味着该方法始终是开放的，可以进行修改。
这里还需要注意的一点是，该方法也没有遵循单一责任原则。因为这里的方法要做不止一件事，比如计算不止一种类型的利息。

使用开闭原则完善

继承只是实现开闭原则的一种方法。因为继承只是一个面向对象设计(OOD)的基本支柱，允许扩展现有类的功能。
为了实现开闭原则，可以使用接口、抽象类、抽象方法和虚方法，而不是在扩展功能时继承它们。
因此，储蓄帐户的前一个问题可以如下所示解决。
在这里插入图片描述

Interface ISavingAccount  
{  //Other method and property and code  decimal CalculateInterest();  
}  Public Class RegularSavingAccount : ISavingAccount  
{  //Other method and property and code related to Regular Saving account  Public decimal CalculateInterest()  {  //Calculate interest for regular saving account based on rules and   // regulation of bank  Interest = balance * 0.4;  If(balance < 1000) interest -= balance * 0.2;  If(balance < 50000) interest += amount * 0.4;  }  
}  Public Class SalarySavingAccount : ISavingAccount  
{  //Other method and property and code related to Salary Saving account`  Public decimal CalculateInterest()  {  //Calculate interest for saving account based on rules and regulation of   //bank  Interest = balance * 0.5;  }  
}

在上述代码中，创建了两个新的类，即从 IsavingAccount 继承的 RgularSavingAccount 和 SalarySavingAccount。
因此，如果银行添加了一个新帐户，那么就不需要修改现有类的逻辑，只需通过继承接口来扩展功能即可。
最后，前面的例子实现了开闭原则，因为不需要修改现有的已实现逻辑，而且它允许扩展添加新的逻辑。
前面的示例还实现了单一责任原则，因为每个类或函数只执行一个任务。
注意: 这里创建了一个接口作为示例。可以有一个由新的储蓄帐户类型实现的 SavingAccount 的抽象类。

不遵循开闭原则的缺点

1、因为类或函数总是允许添加新的逻辑，所以每当添加新的逻辑时，总是需要测试完整的功能。这需要为添加的功能添加一个新的测试用例，并且可能还需要修改由于添加的功能而失败的现有测试用例。
2、它还打破了单一责任原则，因为一个类或函数最终可能会执行多个任务。
3、类或函数的维护变得很困难，因为一个类或函数可能会变成数千行难以理解的代码。