软件设计中最关键的“开闭原则”,究竟指什么呢?

时间:2022-12-23 10:11:11

前言

软件设计原则中有一条很关键的原则是开闭原则,就是所谓的对扩展开放,对修改关闭。个人觉得这条原则是非常重要的,直接关系到你的设计是否具备良好的扩展性,但也是相对比较难以理解和掌握的,究竟怎样的代码改动才被定义为“扩展”?怎样的代码改动才被定义为“修改”?怎么才算满足或违反“开闭原则”?别急,本文将展开详细阐述。

欢迎关注微信公众号「JAVA旭阳」交流和学习

举个例子好理解

为了更好的解释清楚,直接上例子,这是监控告警的类,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()方法逻辑中添加了接口超时处理逻辑。

这个做法有啥问题呢?

  1. 你竟然调整了check()方法的参数,所有原来调用的地方都要修改,如果很多,这不得恨死你呀。
  2. 修改了 check()函数,相应的单元测试都需要修改。

像这种情况,我们就是完全对原来的代码进行修改,不符合开闭原则。

做法二

这时候,你开动脑瓜,大刀阔斧的进行了重构。

  1. 引入了ApiStatInfo类,封装了check的入参信息。
public class ApiStatInfo {// 省略 constructor/getter/setter 方法
	private String api; 
    private long requestCount; 
    private long errorCount;
    private long durationOfSeconds;  
} 
  1. 引入 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, "..."); 
    } 
} 
  1. 修改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); 
        } 
    } 
}
  1. 上层单例类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); 
    } 
}

终于你重构完一开始的逻辑了, 在这个基础上,针对每秒钟接口超时请求个数超过某个最大阈值就告警这个需求,我们又该如何改动代码呢?

  1. ApiStatInfo类添加新字段
public class ApiStatInfo {// 省略 constructor/getter/setter 方法
	private String api; 
    private long requestCount; 
    private long errorCount; 
    private long durationOfSeconds; 
    private long timeoutCount; // 改动一:添加新字段
 } 
  1. 添加新的处理器类TimeoutAlertHandler
public class TimeoutAlertHandler extends AlertHandler {// 省略代码...}
  1. 修改ApplicationContext类添加注册TimeoutAlertHandler
public 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)); 
    } 
    //... 省略其他未改动代码
}
  1. 调用告警处理的地方设置参数
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了怎么办?这时候,我们是不是定义一个发消息的接口,让上层直接调用接口即可。

软件设计中最关键的“开闭原则”,究竟指什么呢?

总结

本文讲解了软件设计中个人认为最重要的一个设计原则,开闭原则,即对扩展开放,对修改关闭,这会指导我们写出扩展性良好的代码,设计出扩展性更好的架构。

欢迎关注微信公众号「JAVA旭阳」交流和学习
更多学习资料请移步:程序员成神之路