OCP原则

系统管理员 2021-10-01 09:10 180阅读 0赞

本文为极客时间《设计模式之美》的读书笔记

# 介绍 #

Open Closed Principle，简写为 OCP。它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

这个描述比较简略，如果我们详细表述一下，那就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

**注**：

## 我对于ocp原则的理解 ##

对扩展开放，对修改关闭，作者下文中的通过粗粒度或者细粒度的角度来分析，所谓的“扩展”，“修改”都是相对的，我感觉可能都没说的太到位，我认为可以这么理解：业务代码有主业务代码和非主业务代码两类，我们要保证的是，主业务代码逻辑清晰且可以扩展和尽量不修改，而非主业务代码中借助了一些设计思想在里面，主业务代码调用非主业务代码，就相当于是主业务代码通过客户端（非主业务代码对外暴露的接口）调用一个封装好的应用，未来业务逻辑的扩展和修改都是在非主业务代码中完成，主业务代码对于客户端即非主业务代码的变动低感知,从而满足ocp原则。

# 实例阐述 #

## 不满足OCP原则的代码 ##

结合 API 接口监控告警的代码的实例来理解OCP。

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

public class Alert {
      private AlertRule rule;
      private Notification notification;
    
      public Alert(AlertRule rule, Notification notification) {
        this.rule = rule;
        this.notification = notification;
      }
      //当接口的 TPS 超过某个预先设置的最大值时，以及当接口请求出错数大于某个最大允许值时，就会触发告警，通知接口的相关负责人或者团队。
      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, "...");
        }
      }
    }

现在，如果我们需要添加一个功能，当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知。这个时候，主要的改动有两处：

*  第一处是修改 check() 函数的入参，添加一个新的统计数据 timeoutCount，表示超时接口请求数；
 *  第二处是在 check() 函数中添加新的告警逻辑。具体的代码改动如下所示：

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() 函数，相应的单元测试都需要修改。

注：

其实测试的用例数，一直都是一个检验代码质量的一个量化标准，两者关系成反比，即代码质量越高，用例数越少。

## 基于OCP原则重构 ##

重构的内容主要包含两部分

*  第一部分是将 check() 函数的多个入参封装成 ApiStatInfo 类；
 *  第二部分是引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中。具体的代码实现如下所示：

//主业务代码
 public class Alert {
 private List<AlertHandler> alertHandlers = new ArrayList<>();
 
 public void addAlertHandler(AlertHandler alertHandler) {
 this.alertHandlers.add(alertHandler);
 }
 //作者这里for循环用的非常妙
 public void check(ApiStatInfo apiStatInfo) {
 for (AlertHandler handler : alertHandlers) {
 handler.check(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子类 TpsAlertHandler、ErrorAlertHandler
 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 的重构，我们再来看下，重构之后的 Alert 该如何使用呢？具体的使用代码我也写在这里了。

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

//这个就相当于Alert的客户端，在所有的设计模式中非常常见，对于一个封装好的代码群上面在抽出来一层作为客户端代码，从而实现主业务代码对于非主业务代码尽量解耦
    //从而达到ocp的目的
    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);
      }
    }

## 基于OCP原则重构后的扩展 ##

现在，我们再来看下，基于重构之后的代码，如果再添加上面讲到的那个新功能，每秒钟接口超时请求个数超过某个最大阈值就告警，我们又该如何改动代码呢？主要的改动有下面四处。

*  第一处改动是：在 ApiStatInfo 类中添加新的属性 timeoutCount。
 *  第二处改动是：添加新的 TimeoutAlertHander 类。
 *  第三处改动是：在 ApplicationContext 类的 initializeBeans() 方法中，往 alert 对象中注册新的 timeoutAlertHandler。
 *  第四处改动是：在使用 Alert 类的时候，需要给 check() 函数的入参 apiStatInfo 对象设置 timeoutCount 的值。改动之后的代码如下所示：

改动后代码

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 类添加单元测试，老的单元测试都不会失败，也不用修改。

注：

下面作者结合上面的例子阐述他的理解

# 修改代码就意味着违背开闭原则吗？ #

看了上面重构之后的代码，你可能还会有疑问：在添加新的告警逻辑的时候，尽管改动二（添加新的 handler 类）是基于扩展而非修改的方式来完成的，但改动一、三、四貌似不是基于扩展而是基于修改的方式来完成的，那改动一、三、四不就违背了开闭原则吗？

## 改动一:往 ApiStatInfo 类中添加新的属性 timeoutCount ##

实际上，我们不仅往 ApiStatInfo 类中添加了属性，还添加了对应的 getter/setter 方法。那这个问题就转化为：给类中添加新的属性和方法，算作“修改”还是“扩展”？

我们再一块回忆一下开闭原则的定义：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。从定义中，我们可以看出，开闭原则可以应用在不同粒度的代码中，可以是模块，也可以类，还可以是方法（及其属性）。同样一个代码改动，在粗代码粒度下，被认定为“修改”，在细代码粒度下，又可以被认定为“扩展”。比如，改动一，添加属性和方法相当于修改类，在类这个层面，这个代码改动可以被认定为“修改”；但这个代码改动并没有修改已有的属性和方法，在方法（及其属性）这一层面，它又可以被认定为“扩展”。

实际上，我们也没必要纠结某个代码改动是“修改”还是“扩展”，更没必要太纠结它是否违反“开闭原则”。我们回到这条原则的设计初衷：只要它没有破坏原有的代码的正常运行，没有破坏原有的单元测试，我们就可以说，这是一个合格的代码改动。

## 改动三和改动四 ##

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

我来解释一下。在重构之后的 Alert 代码中，我们的核心逻辑集中在 Alert 类及其各个 handler 中，当我们在添加新的告警逻辑的时候，Alert 类完全不需要修改，而只需要扩展一个新 handler 类。如果我们把 Alert 类及各个 handler 类合起来看作一个“模块”，那模块本身在添加新的功能的时候，完全满足开闭原则。而且，我们要认识到，添加一个新功能，不可能任何模块、类、方法的代码都不“修改”，这个是做不到的。类需要创建、组装、并且做一些初始化操作，才能构建成可运行的的程序，这部分代码的修改是在所难免的。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。

# 如何做到“对扩展开放、修改关闭”？ #

作者在原文中对于这块写了很多内容，这里不妨按照我的理解整理出来。

## 判断一段代码是否易扩展的“金标准”： ##

*  开闭原则讲的就是代码的扩展性问题，是判断一段代码是否易扩展的“金标准”
    
     *  如果某段代码在应对未来需求变化的时候，能够做到“对扩展开放、对修改关闭”，那就说明这段代码的扩展性比较好。所以，问如何才能做到“对扩展开放、对修改关闭”，也就粗略地等同于在问，如何才能写出扩展性好的代码。

## 写出扩展性好的代码前提： ##

* 我们要时刻具备扩展意识、抽象意识、封装意识。这些“潜意识”可能比任何开发技巧都重要。

## 写代码前的一些思考 ##

* 在写代码的时候，我们要多花点时间往前多思考一下，这段代码未来可能有哪些需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到“对扩展开放、对修改关闭”。
 * 在识别出代码可变部分和不可变部分之后，我们要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。

## 最常用来提高代码扩展性的方法 ##

*  多态
 *  依赖注入
 *  基于接口而非实现编程
 *  大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）。

## OCP原则的边界 ##

*  不要过度设计
    
     *  即便我们对业务、对系统有足够的了解，那也不可能识别出所有的扩展点，即便你能识别出所有的扩展点，为这些地方都预留扩展点，这样做的成本也是不可接受的。我们没必要为一些遥远的、不一定发生的需求去提前买单，做过度设计。
 *  识别业务的不变和变
    
     *  我们要针对业务中在未来可能会变的地方进行一定程度上的设计，将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。
     *  所有的变和不变都是相对的，我们可以对以下场景进行扩展设：
        
         *  一些比较确定的、短期内可能就会扩展，
         *  需求改动对代码结构影响比较大的情况
         *  扩展成本不高的地方
     *  在编写代码的时候之后，我们就可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。