软件设计中最关键的开闭原则，到底指什么？

　　前言
　　软件设计原则中有一条很关键的原则是开闭原则，就是所谓的对扩展开放，对修改关闭。个人觉得这条原则是非常重要的，直接关系到你的设计是否具备良好的扩展性，但也是相对比较难以理解和掌握的，究竟怎样的代码改动才被定义为＂扩展＂？怎样的代码改动才被定义为＂修改＂？怎么才算满足或违反＂开闭原则＂？别急，本文将展开详细阐述。举个例子好理解
　　为了更好的解释清楚，直接上例子，这是监控告警的类，Alert是监控告警类，AlertRule存储告警规则信息，Notification是告警通知类。public class Alert {      // 存储告警规则     private AlertRule rule;      // 告警通知类, 支持邮件、短信、微信、手机等多种通知渠道。     private Notification notification;  	public Alert(AlertRule rule, Notification notification) {          this.rule = rule;          this.notification = notification;      }      // 校验是否进行告警     public void check(String api, long requestCount, long errorCount, long durationOfSeconds) {         // 计算请求的tps         long tps = requestCount / durationOfSeconds;          // 如果tps大于阈值进行告警         if (tps > rule.getMatchedRule(api).getMaxTps()) {               notification.notify(NotificationEmergencyLevel.URGENCY, ＂...＂);          }          // 如果错误次数大于规则阈值进行告警         if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {              notification.notify(NotificationEmergencyLevel.SEVERE, ＂...＂);          }      }  }
　　这个告警Alert的核心业务逻辑主要集中在check()函数中当接口的 TPS 超过某个预先设置的最大值时，触发告警，发送通知。当接口请求出错数大于某个最大允许值时，就会触发告警，通知接口的相关负责人或者团队。
　　现在来了个新的需求，当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知。这个时候，我们该如何改动代码呢？做法一
　　这简单，你可能直接开工就写出下面的代码了。public class Alert {      // ... 省略 AlertRule/Notification 属性和构造函数...      // 改动一：添加参数 timeoutCount      public void check(String api, long requestCount, long errorCount, long timeoutCount) {     long tps = requestCount / durationOfSeconds;      if (tps > rule.getMatchedRule(api).getMaxTps()) {          notification.notify(NotificationEmergencyLevel.URGENCY, ＂...＂);      }      if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {          notification.notify(NotificationEmergencyLevel.SEVERE, ＂...＂);      }     // 改动二：添加接口超时处理逻辑     long timeoutTps = timeoutCount / durationOfSeconds;     if (timeoutTps > rule.getMatchedRule(api).getMaxTimeoutTps()) {         notification.notify(NotificationEmergencyLevel.URGENCY, ＂...＂);      }  }
　　修改点如下：check()方法新增了timeoutCount参数。check()方法逻辑中添加了接口超时处理逻辑。
　　这个做法有啥问题呢？你竟然调整了check()方法的参数，所有原来调用的地方都要修改，如果很多，这不得恨死你呀。修改了 check()函数，相应的单元测试都需要修改。
　　像这种情况，我们就是完全对原来的代码进行修改，不符合开闭原则。做法二
　　这时候，你开动脑瓜，大刀阔斧的进行了重构。引入了ApiStatInfo类，封装了check的入参信息。public class ApiStatInfo {// 省略 constructor/getter/setter 方法 	private String api;      private long requestCount;      private long errorCount;     private long durationOfSeconds;   } 引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中 public abstract class AlertHandler {      protected AlertRule rule;     protected Notification notification;           public AlertHandler(AlertRule rule, Notification notification) { 		this.rule = rule;          this.notification = notification;      }      public abstract void check(ApiStatInfo apiStatInfo);  }  // TPS的告警处理器 public class TpsAlertHandler extends AlertHandler {     public TpsAlertHandler(AlertRule rule, Notification notification) {          super(rule, notification);      }           @Override     public void check(ApiStatInfo apiStatInfo) {          long tps = apiStatInfo.getRequestCount()/ apiStatInfo.getDurationOfSeconds;         if (tps > rule.getMatchedRule(apiStatInfo.getApi()).getMaxTps()) {              notification.notify(NotificationEmergencyLevel.URGENCY, ＂...＂);          }     }  }  // 错误次数告警处理器 public class ErrorAlertHandler extends AlertHandler {      public ErrorAlertHandler(AlertRule rule, Notification notification){          super(rule, notification);      }      @Override     public void check(ApiStatInfo apiStatInfo) {          if (apiStatInfo.getErrorCount() > rule.getMatchedRule(apiStatInfo.getApi())              notification.notify(NotificationEmergencyLevel.SEVERE, ＂...＂);      }  } 修改Alert类，添加各种告警处理器。public class Alert {      private List alertHandlers = new ArrayList<>();      public void addAlertHandler(AlertHandler alertHandler) {          this.alertHandlers.add(alertHandler);      }           public void check(ApiStatInfo apiStatInfo) {          // 遍历各种告警处理器         for (AlertHandler handler : alertHandlers) {              handler.check(apiStatInfo);          }      }  }上层单例类ApplicationContext创建、组装、使用Alert类public class ApplicationContext {      private AlertRule alertRule;      private Notification notification;      private Alert alert;           public void initializeBeans() {         alertRule = new AlertRule(/*. 省略参数.*/); // 省略一些初始化代码 		notification = new Notification(/*. 省略参数.*/); // 省略一些初始化代码 		alert = new Alert();         // 添加告警处理器         alert.addAlertHandler(new TpsAlertHandler(alertRule, notification));          alert.addAlertHandler(new ErrorAlertHandler(alertRule, notification));      }       // 返回告警器Alert     public Alert getAlert() { return alert; }  	// 饿汉式单例     private static final ApplicationContext instance = new ApplicationContext();          private ApplicationContext() {          instance.initializeBeans();      }           public static ApplicationContext getInstance() {          return instance;      } }  public class Demo {      public static void main(String[] args) {          ApiStatInfo apiStatInfo = new ApiStatInfo();  // ... 省略设置 apiStatInfo 数据值的代码 		// 进行告警操作         ApplicationContext.getInstance().getAlert().check(apiStatInfo);      }  }
　　终于你重构完一开始的逻辑了, 在这个基础上，针对每秒钟接口超时请求个数超过某个最大阈值就告警这个需求，我们又该如何改动代码呢？ApiStatInfo类添加新字段public class ApiStatInfo {// 省略 constructor/getter/setter 方法 	private String api;      private long requestCount;      private long errorCount;      private long durationOfSeconds;      private long timeoutCount; // 改动一：添加新字段  } 添加新的处理器类TimeoutAlertHandlerpublic class TimeoutAlertHandler extends AlertHandler {// 省略代码...}修改ApplicationContext类添加注册TimeoutAlertHandlerpublic class ApplicationContext {     .... 	public void initializeBeans() {          alertRule = new AlertRule(/*. 省略参数.*/); // 省略一些初始化代码 		notification = new Notification(/*. 省略参数.*/); // 省略一些初始化代码 		alert = new Alert();          alert.addAlertHandler(new TpsAlertHandler(alertRule, notification));          alert.addAlertHandler(new ErrorAlertHandler(alertRule, notification));          // 改动三：注册 handler          alert.addAlertHandler(new TimeoutAlertHandler(alertRule, notification));      }      //... 省略其他未改动代码 }调用告警处理的地方设置参数public class Demo {      public static void main(String[] args) {          ApiStatInfo apiStatInfo = new ApiStatInfo();          // ... 省略 apiStatInfo 的 set 字段代码         apiStatInfo.setTimeoutCount(289); // 改动四：设置 tiemoutCount 值          ApplicationContext.getInstance().getAlert().check(apiStatInfo);      } }
　　有没有发现，重构完成以后代码的扩展性特别好。如果又有新的告警处理，我只需要新加一个handler类, 并且注册进去，而不用修改原来的check逻辑，也只需要为新增的类写单元测试。这种情况就是很符合开闭原则的。
　　可能你会纠结我也明明修改代码了，怎么就是对修改关闭了呢？第一个修改的地方是向 ApiStatInfo 类中添加新的属性 timeoutCount。实际上，开闭原则可以应用在不同粒度的代码中，可以是模块，也可以类，还可以是方法（及其属性）。同样一个代码改动，在粗代码粒度下，被认定为＂修改＂，在细代码粒度下，又可以被认定为＂扩展＂。比如这里的添加属性和方法相当于修改类，在类这个层面，这个代码改动可以被认定为＂修改＂；但这个代码改动并没有修改已有的属性和方法，在方法（及其属性）这一层面，它又可以被认定为＂扩展＂。另外一个修改的地方是在 ApplicationContext 类的 initializeBeans() 方法中，往 alert 对象中注册新的 timeoutAlertHandler；在使用 Alert 类的时候，需要给check() 函数的入参 apiStatInfo 对象设置 timeoutCount 的值。首先说明添加一个新功能，不可能任何模块、类、方法的代码都不＂修改＂，这个是不可能的。主要看修改的是什么内容，这里的修改是上层的代码，而非核心下层的代码，所以是可以接受的。如何理解开闭原则？
　　前面通过一个例子详细阐述了开闭原则的核心思想，对修改关闭，对扩张开放，这里再次做一个总结，让大家进一步理解开闭原则。
　　添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。关于定义，我们有两点要注意。第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发，而且尽量修改的是上层的代码，而非底层或者和核心逻辑的代码。第二点是，同样的代码改动，在粗代码粒度下，可能被认定为＂修改＂；在细代码粒度下，可能又被认定为＂扩展＂，比如对于一个类添加一个字段或者方法，在某些情况下我们也可以认为是扩展。开闭原则一定是好的吗？
　　开闭原则并不是没有条件的。有些情况下，代码的扩展性会跟可读性相冲突。比如，我们之前举的 Alert 告警的例子。为了更好地支持扩展性，我们对代码进行了重构，重构之后的代码要比之前的代码复杂很多，理解起来也更加有难度。很多时候，我们都需要在扩展性和可读性之间做权衡。在某些场景下，代码的扩展性很重要，我们就可以适当地牺牲一些代码的可读性；在另一些场景下，代码的可读性更加重要，那我们就适当地牺牲一些代码的可
　　扩展性。
　　在我们之前举的 Alert 告警的例子中，如果告警规则并不是很多、也不复杂，那 check() 函数中的 if 语句就不会很多，代码逻辑也不复杂，代码行数也不多，那最初的第一种代码实现思路简单易读，就是比较合理的选择。相反，如果告警规则很多、很复杂，check()函数的 if 语句、代码逻辑就会很多、很复杂，相应的代码行数也会很多，可读性、可维护性就会变差，那重构之后的第二种代码实现思路就是更加合理的选择了。总之，这里没有一个放之四海而皆准的参考标准，全凭实际的应用场景来决定。怎么做到＂对扩展开放、修改关闭＂？
　　开闭原则，本质上就是让你写的程序扩展性好，这需要你平时慢慢的积累和学习，需要时刻具备扩展意识、抽象意识、封装意识。这些＂潜意识＂可能比任何开发技巧都重要。平时需要多多思考，这段代码未来可能有哪些需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到＂对扩展开放、对修改关闭＂。但是切记不要过度设计，不然维护十分困难，也会造成灾难性后果。
　　至于具体的方法论层面，我十分推荐大家要面向接口编程，怎么理解呢？
　　比如现在有个业务需求是将消息发送到kafka，你可能直接在业务代码中调用kafka的API发送消息，这就是面向实现编程，这样非常不好，万一以后不用kafka，该用rocketMQ了怎么办？这时候，我们是不是定义一个发消息的接口，让上层直接调用接口即可。
　　总结
　　本文讲解了软件设计中个人认为最重要的一个设计原则，开闭原则，即对扩展开放，对修改关闭，这会指导我们写出扩展性良好的代码，设计出扩展性更好的架构。