2022-01-02 设计原则--开闭原则与里式替换总结

开闭原则（OCP）

开闭原则（OCP）

开闭原则的英文全称是 Open Closed Principle，简写为 OCP。它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。详细表述一下，那就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

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

添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。关于定义，我们有两点要注意。第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。第二点是，同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。

不是基于开闭原则的设计
/**
 * Alert 存储告警规则，可以自由设置。
 * Notification 是告警通知类，支持邮件、短信、微信、手机等多种通知渠道。
 * NotificationEmergencyLevel 表示通知的紧急程度，包括 SEVERE（严重）、
 * URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要），不同的紧急程度对应不同的发送渠道。
 *
 * API接口监控告警需求描述：
 *
 * 现有功能：1.当接口的 TPS 超过某个预先设置的最大值时，触发告警，通知接口的相关负责人或者团队。
 * 2.当接口请求出错数大于某个最大允许值时，触发告警，通知接口的相关负责人或者团队。
 * 新增需求：当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知
 */
public class Alert {

    private AlertRule rule;

    private Notification notification;

    public Alert(AlertRule rule, Notification notification) {
        this.rule = rule;
        this.notification = notification;
    }

    //逻辑如下：
    // 改动一：添加参数timeoutCount
    //TODO: 直接改动存在两个问题：1.调用这个接口的代码都要做相应的修改；2.相应的单元测试都需要修改
    public void check(String api, long requestCount, long errorCount, long durationOfSeconds, long timeoutCount){
        long tps = requestCount/durationOfSeconds;
        if(tps > rule.getMatchedRule(api).getMaxTps()){
            notification.notify(NotificationEmergencyLevel.URGENCY,"TPS exceeded threshold.");
        }
        if(errorCount > rule.getMatchedRule(api).getMaxErrorCount()){
            notification.notify(NotificationEmergencyLevel.SEVERE, "ErrorCount exceeded threshold.");
        }
        //改动二：添加接口超时处理逻辑
        long timeoutTps = timeoutCount/durationOfSeconds;
        if(timeoutTps > rule.getMatchedRule(api).getMaxTimeoutTps()){
            notification.notify(NotificationEmergencyLevel.URGENCY, "TimeoutTps exceeded threshold.");
        }
    }
}

基于开闭原则的设计
 
/**
 * Alert类
 * 基于OCP设计原则，首先对代码重构，
 * 第一部分是将 check() 函数的多个入参封装成 ApiStatInfo 类；
 * 第二部分是引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中。
 *
 * 基于重构之后的代码，如果再添加上面讲到的那个新功能，每秒钟接口超时请求个数超过某个最大阈值就告警，
 * 主要的改动有下面四处。
 * 第一处改动是：在 ApiStatInfo 类中添加新的属性 timeoutCount。
 * 第二处改动是：添加新的 TimeoutAlertHander 类。
 * 第三处改动是：在 ApplicationContext 类的 initializeBeans() 方法中，往 alert
 *            对象中注册新的 timeoutAlertHandler。
 * 第四处改动是：在使用 Alert 类的时候，需要给 check() 函数的入参 apiStatInfo 对象设置 timeoutCount 的值。
 *
 * 基于开闭原则的设计优点：
 *    1.代码更加灵活和易扩展。添加新的需求，只需要基于扩展的方式创建新的handler类即可，
 *      不需要改动原来的 check() 函数的逻辑，即--调用这个接口的代码无需修改。
 *    2.只需要为新的handler类添加单元测试，老的单元测试都不会失败，也不用修改。
 */
public class Alert {
    private List<AlertHandler> handlerList = new ArrayList<AlertHandler>();

    public void addHandler(AlertHandler handler) {
        this.handlerList.add(handler);
    }

    public void check(ApiStatInfo apiStatInfo) {
        for (AlertHandler handler : handlerList) {
            handler.check(apiStatInfo);
        }
    }
}

@Getter
public class ApiStatInfo {

    private String api;

    private long requestCount;

    private long errorCount;

    private long timeoutCount;

    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,"TPS exceeded threshold.");
        }
    }
}

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, "ErrorCount exceeded threshold.");
        }
    }
}

public class TimeoutAlertHander extends AlertHandler{

    public TimeoutAlertHander(AlertRule rule, Notification notification) {
        super(rule, notification);
    }

    @Override
    public void check(ApiStatInfo apiStatInfo) {
        long timeoutTps = apiStatInfo.getTimeoutCount()/apiStatInfo.getDurationOfSeconds();
        if(timeoutTps > rule.getMatchedRule(apiStatInfo.getApi()).getMaxTimeoutTps()){
            notification.notify(NotificationEmergencyLevel.URGENCY, "TimeoutTps exceeded threshold.");
        }
    }
}

/**
 * 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 RocketMQNotification();
        alert = new Alert();

        alert.addHandler(new TpsAlertHandler(alertRule,notification));
        alert.addHandler(new ErrorAlertHandler(alertRule,notification));
        alert.addHandler(new TimeoutAlertHander(alertRule,notification));
    }

    private static final ApplicationContext instance = new ApplicationContext();

    private ApplicationContext() {
        initializeBeans();
    }

    public static ApplicationContext getInstance(){

        return instance;
    }

    public Alert getAlert() {
        return alert;
    }
}

public class Demo {
    public static void main(String[] args) {
        ApiStatInfo apiStatInfo = new ApiStatInfo();

        ApplicationContext.getInstance().getAlert().check(apiStatInfo);
    }
}

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

我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点（PS:此处与OOD中基于业务模型来进行类的设计有异曲同工之妙），以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。
```
// 这一部分体现了抽象意识
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) {
    //...    
  }
}
```

里式替换（LSP）

里式替换原则的英文翻译是：Liskov Substitution Principle，缩写为 LSP。英文原话是这样的：Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。

里式替换原则是用来指导，继承关系中子类该如何设计的一个原则。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：

函数声明要实现的功能；

父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。那子类的设计就违背里式替换原则。
对输入、输出、异常的约定；

在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。
注释中所罗列的任何特殊说明。

父类中定义的 withdraw() 提现函数的注释是这么写的：“用户的提现金额不得超过账户余额……”，而子类重写 withdraw() 函数之后，针对 VIP 账号实现了透支提现的功能，也就是提现金额可以大于账户余额，那这个子类的设计也是不符合里式替换原则的。

理解这个原则，我们还要弄明白里式替换原则跟多态的区别。虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。

/**
 * 需求描述：父类 Transporter 使用 org.apache.http库中的HttpClient类来传输网络数据。
 * 子类 SecurityTransporter 继承父类Transporter，增加了额外的功能，支持传输appId和appToken安全认证信息
 *
 */
public class Transporter {
    private HttpClient httpClient;

    public Transporter(HttpClient clihttpClientent) {
        this.httpClient = httpClient;
    }

    public Response sendRequest(Request request) throws IOException {
        //use httpClient to send request
        return new Response(httpClient.execute(request.getHttpRequest()));
    }
}

public class SecurityTransporter extends Transporter {
    private String appId;

    private String appToken;

    public SecurityTransporter(HttpClient httpClient, String appId, String appToken) {
        super(httpClient);
        this.appId = appId;
        this.appToken = appToken;
    }

    @Override
    public Response sendRequest(Request request) throws IOException {
      //里氏替换就是子类完美继承父类的设计初衷，并做了增强。
        if(StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)){
            request.addPayload("app-id", appId);
            request.addPayload("app-token", appToken);
        }
        return super.sendRequest(request);
    }
}

反例
  /**
 * SecurityTransporter类
 *
 * 在改造之后的代码中如果传递给 demoFunction()函数的是子类SecurityTransporter对象，
 * 那demoFunction()有可能会有异常抛出。尽管代码中抛出的是运行时异常(Runtime Exception),
 * 我们可以不在代码中显式地捕获处理，但子类替换父类传递进demoFunction函数之后，整个程序的逻辑行为有了改变。
 * 虽然 改造之后的代码仍然可以通过Java的多态语法 ，动态地用子类SecurityTransporter来替换父类Transporter,
 * 也并不会导致程序编译或者运行报错。但是，从设计思路上来讲，SecurityTransporter 的设计是不符合里式替换原则的。
 
 */
  public class SecurityTransporter extends Transporter {
    private String appId;

    private String appToken;

    public SecurityTransporter(HttpClient httpClient, String appId, String appToken) {
        super(httpClient);
        this.appId = appId;
        this.appToken = appToken;
    }

    @Override
    public Response sendRequest(Request request) throws IOException, NoAuthorizationRuntimeException {
        if(StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)){
            throw new NoAuthorizationRuntimeException();
        }
        request.addPayload("app-id", appId);
        request.addPayload("app-token", appToken);

        return super.sendRequest(request);
    }
}
  
  public class Demo {

    public void demoFunction(Transporter transporter) throws IOException {
        Request request = new Request();
        Response response = transporter.sendRequest(request);
    }

    public static void main(String[] args) {
        Demo demo = new Demo();
        //里式替换原则
        demo.demoFunction(new SecurityTransporter(httpClient,"appId","appToken"));
    }

}

禁止转载，如需转载请通过简信或评论联系作者。

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 203,324评论 5赞 476
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 85,303评论 2赞 381
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 150,192评论 0赞 337
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 54,555评论 1赞 273
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 63,569评论 5赞 365
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 48,566评论 1赞 281
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 37,927评论 3赞 395
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,583评论 0赞 257
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 40,827评论 1赞 297
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,590评论 2赞 320
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 37,669评论 1赞 329
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,365评论 4赞 318
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 38,941评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 29,928评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,159评论 1赞 259
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 42,880评论 2赞 349
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,399评论 2赞 342

2022-01-02 设计原则--开闭原则与里式替换总结

开闭原则（OCP）

里式替换（LSP）

推荐阅读更多精彩内容