开闭原则-OCP¶
Open Closed Principle
重要
开闭原则，是架构治理的根本哲学。最为重要！
备注
software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification. 对扩展开放、对修改关闭。开闭原则是 SOLID 中最难理解、最难掌握，同时也是最有用的一条原则。
备注
开闭原则告诉我们，应尽量通过扩展软件实体的行为来应对变化，满足新的需求，而不是通过修改现有代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
备注
开闭原则的背后，是推崇模块业务的确定性。我们可以修改模块代码的缺陷（Bug），但不要去随意调整模块的业务范畴，增加功能或减少功能都并不鼓励。这意味着，它认为模块的业务变更是需要极其谨慎的，需要经得起推敲的。
备注
『每一个模块都应该是可完成的』与其修改模块的业务，不如实现一个新业务。只要业务的分解一直被正确执行的话，实现一个新的业务模块来完成新的业务范畴，是一件极其轻松的事情。从这个角度来说，开闭原则鼓励写 “只读” 的业务模块，一经设计就不可修改，如果要修改业务就直接废弃它，转而实现新的业务模块。
备注
开闭原则并非不鼓励修改软件的源代码来响应新需求。开闭原则关注的焦点是模块，并不是最终形成的软件。模块应该坚持自己的业务不变，这是开闭原则所鼓励的。
这一原则最有用是因为:
很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的
特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。
最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，
以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）
如何理解 “对扩展开放、对修改关闭”:
添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），
而非修改已有代码（修改模块、类、方法、属性等）的方式来完成
注:
1. 开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发
2. 同样的代码改动，在粗代码粒度下，可能被认定为 “修改”；在细代码粒度下，可能又被认定为 “扩展”
如何做到 “对扩展开放、修改关闭”:
我们要时刻具备扩展意识、抽象意识、封装意识。
在写代码的时候，我们要多花点时间思考一下，
这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，
以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，
将新的代码灵活地插入到扩展点上。
开闭原则讲的就是代码的扩展性问题，是判断一段代码是否易扩展的 “金标准”。如果某段代码在应对未来需求变化的时候，能够做到 “对扩展开放、对修改关闭”，那就说明这段代码的扩展性比较好。写出支持 “对扩展开放、对修改关闭” 的代码的关键是预留扩展点。
一些更加偏向顶层的指导思想。为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识。这些 “潜意识” 可能比任何开发技巧都重要。
最合理的做法是，对于一些比较确定的、短期内可能就会扩展，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，我们就可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。
开闭原则也并不是免费的。有些情况下，代码的扩展性会跟可读性相冲突。比如，我们之前举的 Alert 告警的例子。为了更好地支持扩展性，我们对代码进行了重构，重构之后的代码要比之前的代码复杂很多，理解起来也更加有难度。很多时候，我们都需要在扩展性和可读性之间做权衡。在某些场景下，代码的扩展性很重要，我们就可以适当地牺牲一些代码的可读性；在另一些场景下，代码的可读性更加重要，那我们就适当地牺牲一些代码的可扩展性。
这里没有一个放之四海而皆准的参考标准，全凭实际的应用场景来决定。
示例¶
简介:
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;
}
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, "...");
}
}
}
添加一个功能，当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知:
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, "...");
}
}
}
这样修改的问题:
1. 我们对接口进行了修改，这就意味着调用这个接口的代码都要做相应的修改
2. 修改了 check () 函数，相应的单元测试都需要修改
使用「对扩展开放、对修改关闭」如何做:
重构一下之前的 Alert 代码，让它的扩展性更好一些。
重构的内容主要包含两部分:
1. 将 check () 函数的多个入参封装成 ApiStatInfo 类
2. 引入 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, "...");
}
}
}
重构后的使用:
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 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);
}
}
重构之后的代码，如果再添加上面讲到的那个新功能:
1. 在 ApiStatInfo 类中添加新的属性 timeoutCount
2. 添加新的 TimeoutAlertHander 类
3. 在 ApplicationContext 类的 initializeBeans () 方法中，往 alert 对象中注册新的 timeoutAlertHandler
4. 在使用 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 类添加单元测试，老的单元测试都不会失败，也不用修改。
备注
我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。