开闭原则：基于接口或抽象实现“封闭”，基于实现接口或继承实现“开放”（拓展）。

争哥的第一个例子，AlertHandler为抽象，一般是固定不变的。子类TpsAlertHandler为继承；再看第二个例子，MessageQueue，MessageFormater为接口，具体实现为KafkaMessageQueue和JsonMessageFromatter等。以后替换或者增加其他的AlertHandler和message queue很容易。

两个例子中的抽象类和接口是固定的（封闭），继承或实现是可扩展的。通过“抽象-具体”体现了开闭原则，增加了软件的可维护性。

开闭原则具体应用，需要慢慢积累经验。争哥也说了，首先需要有对业务深刻的理解。其次就是学习一些设计原则和模式了。

补充：
1、Bertrand Meyer 1988 年提出open-closed principle。
2、再推荐一篇经典文章 Robert C. Martin 2006年写的The Open-Closed Principle。不方便下载的话，我放到github上了：https://github.com/gdhucoder/Algorithms4/tree/master/designpattern/pdf

基于一定的粒度（例如模块，类，属性等），扩展是平行地增加，修改是变更更细粒度的子集。扩展和修改和具体的粒度有关。不同的粒度下，扩展和修改定义不同。
我个人以为，扩展的结果是引入了更多的平行结构（例如相似的派生类handler），以及支持这些平行结构的代码（利用多态，在关键的地方使用接口）。这些引入会让代码结构变的扁平一些，但是也更晦涩一些。修改，往往会增加代码的深度（这里指更低粒度的复杂度），例如，文中log例子，修改后，check函数有五个参数，内部的if else逻辑更多。但是，如果从参数以及if作用域的角度，这也可算作扩展。所以，扩展还是修改更本质的区别在于修改发生的粒度和层次。
通常偏好修改发生在更高的层次上，这要求我们能够用接口和组合把系统合理的切分，做到高内聚和低耦合。高内聚可以让修改发生在更高层次上，替换掉整个低层次实现细节。低耦合，可以让模块之间的调用最小化，可以让高层次的修改最小化。
支持高层次的平行结构不是免费的，除非有明确的收益（例如文中隔离Kafka实现细节的例子），不然还是让重构等待到需要的那一刻，预测未来的大部分平行结构其实不会被真正用到。

设计模式_16
# 作业：
开闭原则核心好处是：
- 减少因为新增功能而增加的工作量
- 减少因为新增功能而增加的出错数

# 感想：
之前一直有一些执念，想要找到某一原则非黑即白的分割线。比如开闭原则，有两个极端：
- 任何的“修改”都不能接受
- 任何不能“扩展”的代码都不能接受
然后就进入了“走火入魔”的状态，最终陷入对原则的怀疑。

需求变更对于代码结构影响很大时，要提高对其扩展的权重；读到这里时，我拍了一下大腿，我想，我更加理解开闭原则了。

简单来说，就是尽量减少调用方为了应对而导致的变更。
就例如本文的例子，为了应对变化需要增加函数的参数的时候。所有调用方都需要改代码。
而如果依照开闭原则，则增加handler 以及相应修改即可。并不会影响调用方。

其实个人认为，也是通过了 类似于“中间件”的形式。例如，小明，作为公司代表需要跟各个国外公司的人谈业务。他去跟美国人谈业务，需要学英语；跟日本谈业务，要学日语；跟毛子谈业务，又要学毛子语。
这时候，的解决方案：
1，跟各个国家说好，大家都说英语。或者都说汉语。就算再有其他的国家，也让他强制用英语。
2，小明自己只用汉语。然后谈业务时，带个多语种翻译，去谈业务时把翻译带上。这时候，如果有新的国家需要新的语种，那么就让翻译去掌握更多的语种。
应对今天的例子，翻译掌握的语种，其实就是handler。小明和各国代表谈业务时，各自都不需要变更自己的接口。只需要对【翻译】进行扩展即可。

老师 您好，请教几个问题
AlertHandler 使用的是抽象类，而不是接口。就是为了让子类去继承构造方法吗？
这个扩展跟spring中handlerMapping的写法一样，类似于策略模式吧？
单例模式的时候 使用静态代码块来初始化添加handler 随着类加载一次是不是就不用搞成单例的了？
 static{
        alertRule = new AlertRule(/*.省略参数.*/); //省略一些初始化代码
        notification = new Notification(/*.省略参数.*/); //省略一些初始化代码
         alert = new Alert(alertRule,notification);
         alert.addAlertHandler(new TpsAlertHandler(alertRule, notification));
         alert.addAlertHandler(new ErrorAlertHandler(alertRule, notification));
    }

我们是不是可以把实现类（不同的handler）放到配置文件中。使用jdk的spi扩展机制。更加灵活一些？

老师您好，我把代码实践了后发现， 单例初始化那块可能有点问题。private static final ApplicationContext instance = new ApplicationContext();

    private ApplicationContext() {
        instance.initializeBeans();
    }
这个“instance”报了空指针。