设计模式之美-课程笔记8-设计原则2-开闭原则(OCP)

理论二：如何做到“对扩展开放、修改关闭”？扩展和修改各指什么？

开闭原则比较难理解，因为关于扩展、修改的定义比较难定义。什么样算遵守，什么样算违背了开闭原则。

这条原则是关于扩展性，而扩展性是衡量代码质量很重要的标准。23种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题存在的。

如何理解“对扩展开放、修改关闭”？

开闭原则的英文全称是Open Closed Principle，OCP。他的英文描述是software entities(modules, classes, functions, etc.) should be open for extension, but closed for modification. 软件实体（模块、类、方法）应该对扩展开放，对修改关闭。
1. 说得明白点就是：添加一个新的功能应该是在已有代码的基础上扩展代码（新增模块、类、方法），而非修改已有代码（修改模块、类、方法）。

举个例子🌰

作者给了一段API接口监控告警的代码。其中AlterRule存储警告规则，可以自由设置。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;
  }

  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的入参要增加超时请求个数；
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, "...");
    }
  }
}

这样的设计和修改的问题在于所有使用到这个方法的地方都要修改。所有的单测也需要相应的修改。
这样的改动是基于“修改”来实现的。我们将遵循开闭原则，以易扩展的方式设计和实现修改。

首先重构一下之前的Alert代码

将check的多个入参等装成ApiStateInfo类；
引入handler的概念，将if判断逻辑分散在各个handler中。

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

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

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

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。ApplicationContext 是一个单例类，负责 Alert 的创建、组装（alertRule 和 notification 的依赖注入）、初始化（添加 handlers）工作。单例相当于给Alert feature的调用提供一个抓手、入口。

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

再进行之前说的改动，对于每秒钟接口超时请求个数超过某个最大阈值就告警。

给ApiStatInfo类增加一个属性：超时请求个数timeOutCount;
增加一个handler，在这个handler中的check方法实现这个告警规则；
再initializebean（application context)的时候给单例的alter添加上这个handler。
使用alter的时候，给check函数的入参apiStatInfo对象设置相应的timeOutCount值。

这样基于扩展增加了新的handler，不需要改动原来的check逻辑，也只需要为新的handler增加单测，以前的不会失效。

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

修改代码意味着违反开闭原则吗

上述修改的1/3/4不都是在修改了原来的代码吗？让我们一个个分析：

往ApiStateInfo中增加新的属性timeOutCount
- 我们不仅增加了新的属性，还增加了getter、Setter。
- 在”类“的粒度上我们是在修改类，增加了新的属性；但是在”方法“的粒度上，我们没有改变现有的其他方法，所以这个增加又可以是拓扩展
- 我们不需要纠结（我认同，不需要纠结概念）他是修改还是扩展。回到这个原则的设计初衷就是**没有破坏原有代码的运行，没有破坏单测。**
改动3、4。虽然在各个层面都是修改，但是他们是不可避免的，是可以接受的。
- 我们要认识到，添加一个新功能，不可能任何模块、类、方法的代码都不“修改”，这个是做不到的。类需要创建、组装、并且做一些初始化操作，才能构建成可运行的的程序，这部分代码的修改是在所难免的。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。
  
  细枝末节因为java的语法和代码设计肯定需要增强和修改，但是原来的核心逻辑是没有动的，就是增加了一个handler处理新的逻辑。

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

我一开始确实想不到设计handler。笔者也说了慢慢积累经验。
时刻具备扩展意识，抽象意识，封装意识
在写代码的时候，要花时间多往后思考这段代码可能会有哪些需求变更、如何设计代码结构，事先留好扩展点，以便在未来需求变更时候不需要改动代码整体结构。做到最小代码设计改动情况下，新代码很灵活的插入到扩展点。
在识别代码的可变部分和不可变部分后，我们要将可变部分封装起来，隔离变化，提供抽象化的不可变接口给上层使用。

在众多设计原则，思想，模式中，最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分设计模式（后面详细说）。

多态、依赖注入、基于接口而非实现编程都是同一个哲学（或者说思路），只是从不同角度阐述。

来个例子：我们通过Kafka发送异步消息。我们在这个功能的开发中我们要学会将其抽象成一组跟具体消息队列无关的异步消息接口。以便我们在以后用RabbitMQ替换Kafka的时候很方便。

// 这一部分体现了抽象意识
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) {
    //...    
  }
}

如何在项目中灵活应用这个原则？

如何识别扩展点：
1. 如果是业务导向的系统，我们需要尽可能了解业务，能够知道当下未来可能需要支持的业务需求。
2. 如果是跟业务无关的偏底层的需求，比如框架组件类库等，你需要了解他们可能会如何被使用，打算添加什么功能，使用者未来可能会有什么需求？
不过还是要适度，避免过度设计。
所以对于一些比较确定的、短期能可能扩展，或者需求改动对代码结构影响比较大的情况，或者是实现成本不高的扩展点，在写代码的时候可以是先做扩展性设计。
但是对于不确定未来要支持的需求，扩展比较复杂的扩展点，可以等需求驱动再去做通过重构的方式来支持扩展。
扩展可能会和可读性冲突。Alert代码在考虑过扩展性之后的重构设计和理解上都增加了一些难度。我们需要做一些权衡。

我之前对于一些好代码的理解单纯是DRY，也就是不重复的代码。这个思路没错但是现在看来有点初阶或者是浅显了。之前一个需求就是对于多个Object增加一个新的unique id，然后要对他们的格式和唯一性做校验。最开始的设计和实现是在每个Object的manager的save方法中去实现了这个validator，其实每个validator的视线逻辑大概有80%相似，但是操作的Object不同，校验逻辑大概有一些细微的差别。

后面就在一到两周后有了点时间，在做这个function的test的时候做了重构，这次重构是针对的重复代码，把这些validation的逻辑从每个Object的manager中抽离出来，做了一个validator类，其中只有一个静态的validation方法，针对传进来的参数类型确定使用不同的校验细节的增减，这样一下子将代码集中，变得更好维护，而且也减少了代码量，提升了可读性。

但当时review代码的同事就提出了一个建议就是说如果考虑到整个代码的可扩展性，以后如果还要给其他的object增加这个unique id以及类似的校验逻辑，还是会回来改这个validator。这样其实是违反了OCP。

我当时其实想到了将所有的东西放进去一个validator的”弊端“：集中了修改。但是考虑到这个需求以后可能对于我们现有的object已经足够，以后增加其他的object（未知）。

经过他的介绍，再加上又看了这个文章，比较清晰的意识到问题所在。

如果要对那个代码重构，使其更加具有可扩展性，我之前同事说的是：”splitting it into a base class along with a set of different subclasses“。我理解或者说现在可以想到的：

做一个抽象类包含通用的部分；
每个不同的object去继承这个类，针对自己的逻辑增加特定方法；
然后再在使用的地方调用这些方法即可；

这样在增加其他的object需要使用类似的同样可以继承通用的部分，然后依靠多态在自己的xxxObjectValidator类中去实现自己的逻辑。

10K's