继续学习一下SOLID设计原则的第二个原则：开闭原则。开闭原则是SOLID里面最重要的一条原则，因为它是解决代码扩展性问题的，而扩展性是代码质量最重要的衡量标准之一。在 23 种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则

理解开闭原则

开闭原则的英文全称是 Open Closed Principle，简写为 OCP，内容是：软件实体（模块、类、方法等）应该对扩展开放、对修改关闭。详细表述就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等），这里有两个可能的理解误区：

第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。
第二点是，同样的代码改动，在粗代码粒度下，可能被认定为修改；在细代码粒度下，可能又被认定为扩展。

接下来通过持续重构一段代码来体会，主要功能是告警监控系统：

AlertRule 存储告警规则，可以自由设置。check的时候用以和实际情况比较
Notification 是告警通知类，支持邮件、短信、微信、手机等多种通知渠道。NotificationEmergencyLevel 表示通知的紧急程度，包括 SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要），不同的紧急程度对应不同的发送渠道

以下代码分别用来检测接口的tps和errorCount是否不合格。

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) {
    long tps = requestCount / durationOfSeconds;
    if (tps > rule.getMatchedRule(api).getMaxTps()) {
      notification.notify(NotificationEmergencyLevel.URGENCY, "...");
    }
    if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {
      notification.notify(NotificationEmergencyLevel.SEVERE, "...");
    }
  }
}

1 修改方式的重构

现在，如果我们需要添加一个功能，当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时报警，改动有两处：

public class Alert {
  // ...省略AlertRule/Notification属性和构造函数...
  // 改动一：添加参数timeoutCount
  public void check(String api, long requestCount, long errorCount, long timeoutCount, long durationOfSeconds) {
    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函数，相应的单元测试都需要修改

2 扩展方式的重构

如何才能让代码更加具有扩展性呢，需要对代码进行重构：重构的内容主要包含两部分：

第一部分是将 check 函数的多个入参封装成 ApiStatInfo 类；
第二部分是引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中。

重构后代码如下：

报警执行框架Alert

基于List的方式将Alert实现类注册进来

public class Alert {
  private List<AlertHandler> alertHandlers = new ArrayList<>();
  public void addAlertHandler(AlertHandler alertHandler) {
    this.alertHandlers.add(alertHandler);
  }
  public void check(ApiStatInfo apiStatInfo) {
    for (AlertHandler handler : alertHandlers) {
      handler.check(apiStatInfo);
    }
  }
}

数据参数ApiStatInfo

public class ApiStatInfo {//省略constructor/getter/setter方法
  private String api;
  private long requestCount;
  private long errorCount;
  private long durationOfSeconds;
}

抽象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);
}

具体实现的Handler方法

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()).getMaxErrorCount()) {
      notification.notify(NotificationEmergencyLevel.SEVERE, "...");
    }
  }
}

重构之后的Alert需要把各种Handler注册到自己List里，然后执行check，注册处理逻辑到Alert的这个动作可以交给单例模式去做，因为规则只需要注册一遍就行了，不需要每次都重复添加。

ApplicationContext 是一个单例类，负责 Alert 的创建、组装（alertRule 和 notification 的依赖注入）、初始化（添加 handlers）工作。

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));
  }
  public Alert getAlert() { return alert; }
  // 饿汉式单例
  private static final ApplicationContext instance = new ApplicationContext();
  private ApplicationContext() {
    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);
  }
}

那么重构后的改动就是这四个部分：

public class Alert { // 代码未改动... }
public class ApiStatInfo {//省略constructor/getter/setter方法
  private String api;
  private long requestCount;
  private long errorCount;
  private long durationOfSeconds;
  private long timeoutCount; // 改动一：添加新字段
}
public abstract class AlertHandler { //代码未改动... }
public class TpsAlertHandler extends AlertHandler {//代码未改动...}
public class ErrorAlertHandler extends AlertHandler {//代码未改动...}
// 改动二：添加新的handler
public class TimeoutAlertHandler extends AlertHandler {//省略代码...}
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));
    // 改动三：注册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() 函数的逻辑。而且，只需要为新的 handler 类添加单元测试，老的单元测试都不会失败，也不用修改

避免开闭原则思维误区

修改代码就意味着违背开闭原则吗？其实重构后我们也对代码做了修改，例如改动一：往 ApiStatInfo 类中添加新的属性 timeoutCount。其实扩展和修改也是相对而言的

开闭原则是相对代码粒度划分的

基于开闭原则的定义：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。从定义中可以看出开闭原则可以应用在不同粒度的代码中，可以是模块，也可以类，还可以是方法（及其属性）。同样一个代码改动，在粗代码粒度下，被认定为“修改”，在细代码粒度下，又可以被认定为“扩展”。改动一添加属性和方法相当于修改类，在类这个层面，这个代码改动可以被认定为“修改”；但这个代码改动并没有修改已有的属性和方法，在方法（及其属性）这一层面，它又可以被认定为“扩展”。那么该如何衡量呢？抓住一个原则就可以了：只要它没有破坏原有的代码的正常运行，没有破坏原有的单元测试,我们就可以说，这是一个合格的代码改动

只关注核心模块、核心逻辑的开闭性即可

再来分析一下改动三和改动四：在 ApplicationContext 类的 initializeBeans() 方法中，往 alert 对象中注册新的 timeoutAlertHandler；在使用 Alert 类的时候，需要给 check() 函数的入参 apiStatInfo 对象设置 timeoutCount 的值，这两处改动都是在方法内部进行的，不管从哪个层面（模块、类、方法）来讲，都不能算是扩展，而是地地道道的修改。不过，有些修改是在所难免的，是可以被接受的在

重构之后的 Alert 代码中，我们的核心逻辑集中在 Alert 类及其各个 handler 中，当我们在添加新的告警逻辑的时候，Alert 类完全不需要修改，而只需要扩展一个新 handler 类。如果我们把 Alert 类及各个 handler 类合起来看作一个“模块”，那模块本身在添加新的功能的时候，完全满足开闭原则。

添加一个新功能，不可能任何模块、类、方法的代码都不“修改”，这个是做不到的。类需要创建、组装、并且做一些初始化操作，才能构建成可运行的的程序，这部分代码的修改是在所难免的。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则

不是越OCP越好，要兼顾可读性

有时候要避免想的太多，有些情况下，代码的扩展性会跟可读性相冲突。比如， Alert 告警的例子。为了更好地支持扩展性，我们对代码进行了重构，重构之后的代码要比之前的代码复杂很多，理解起来也更加有难度。很多时候，我们都需要在扩展性和可读性之间做权衡。在某些场景下，代码的扩展性很重要，我们就可以适当地牺牲一些代码的可读性，例如告警场景非常多，if分支非常多就适合扩展性；在另一些场景下，例如if分支很少，考虑到成本以及代码的可读性，那我们就适当地牺牲一些代码的可扩展性。

对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求

开闭原则的实现方式

指导具体的方法论之前最好有一个顶级的潜意识指导思想：为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识 ，在写代码的时候要多加思考，这段代码未来可能有哪些需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到“对扩展开放、对修改关闭”

具体的方法论则是：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）

// 这一部分体现了抽象意识
public interface MessageQueue { //... }
public class KafkaMessageQueue implements MessageQueue { //... }
public class RocketMQMessageQueue implements MessageQueue {//...}
public interface MessageFromatter { //... }
public class JsonMessageFromatter implements MessageFromatter {//...}
public class ProtoBufMessageFromatter implements MessageFromatter {//...}
public class Demo {
  private MessageQueue msgQueue; // 基于接口而非实现编程
  public Demo(MessageQueue msgQueue) { // 依赖注入
    this.msgQueue = msgQueue;
  }
  // msgFormatter：多态、依赖注入
  public void sendNotification(Notification notification, MessageFormatter msgFormatter) {
    //...    
  }
}

我们代码中通过 Kafka 来发送异步消息。对于这样一个功能的开发，我们将其抽象成一组跟具体消息队列（Kafka）无关的异步消息接口。所有上层系统都依赖这组抽象的接口编程，并且通过依赖注入的方式来调用。当要替换新的消息队列的时候，比如将 Kafka 替换成 RocketMQ，可以很方便地拔掉老的消息队列实现，插入新的消息队列实现

总结一下

OCP是相对而言的一个概念，在不同代码粒度可能就是不同的结果，所以不能认为OCP就是不改代码，而是尽量让改动更上层，集中在非核心逻辑部分，一个判断依据就是当有新功能添加时不需要改之前的核心实现逻辑并且单元测试都能通。实现OCP的方式有很多，例如依赖注入、基于接口而非实现编程、多态以及各种设计模式。但核心指导思想则是，写代码时候要多思考，要时刻具备扩展意识、抽象意识、封装意识。尽量写符合OCP的代码是正确的，因为这样的代码扩展性强，但是也看场景，当场景没那么复杂或者需求比较固定的时候可以权衡一下实现成本及可读性和扩展性的利弊来做选择。

【Java设计模式经典设计原则】二 SOLID-OCP开闭原则

理解开闭原则

1 修改方式的重构

2 扩展方式的重构

避免开闭原则思维误区

开闭原则是相对代码粒度划分的

只关注核心模块、核心逻辑的开闭性即可

不是越OCP越好，要兼顾可读性

开闭原则的实现方式

总结一下

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

【Java设计模式 经典设计原则】二 SOLID-OCP开闭原则

理解开闭原则

1 修改方式的重构

2 扩展方式的重构

避免开闭原则思维误区

开闭原则是相对代码粒度划分的

只关注核心模块、核心逻辑的开闭性即可

不是越OCP越好，要兼顾可读性

开闭原则的实现方式

总结一下

热门文章

最新文章

相关课程

相关电子书

相关实验场景

【Java设计模式经典设计原则】二 SOLID-OCP开闭原则