实践GoF的23种设计模式：SOLID原则

之前也有写过关于设计模式的文章《使用Go实现GoF的23种设计模式》，但是那个系列写了3篇文章就没再继续了，主要的原因是找不到合适的示例代码。考虑到，如果以类似于“鸭子是否会飞”、“烘焙的制作流程”等贴近生活的事情举例，很难在我们日常的开发中产生联系。（目前应该很少有这些逻辑的软件系统吧）

《实践GoF的23种设计模式》可以看成是《使用Go实现GoF的23种设计模式》系列的重启，吸取了上次烂尾的教训，本次在写文章之前就已经完成了23种设计模式的示例代码实现。和上次不同，本次示例代码使用Java实现，以我们日常开发中经常碰到的一些技术/问题/场景作为切入点，示范如何运用设计模式来完成相关的实现。

前言

从1995年GoF提出23种设计模式到现在，25年过去了，设计模式依旧是软件领域的热门话题。设计模式通常被定义为：

设计模式（ ）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。

从定义上看，设计模式其实是一种经验的总结，是针对特定问题的简洁而优雅的解决方案。既然是经验总结，那么学习设计模式最直接的好处就在于可以站在巨人的肩膀上解决软件开发过程中的一些特定问题。

学习设计模式的最高境界是吃透它们本质思想，可以做到即使已经忘掉某个设计模式的名称和结构，也能在解决特定问题时信手拈来。设计模式背后的本质思想，就是我们熟知的SOLID原则。如果把设计模式类比为武侠世界里的武功招式，那么SOLID原则就是内功内力。通常来说，先把内功练好，再来学习招式，会达到事半功倍的效果。因此，在介绍设计模式之前，很有必要先介绍一下SOLID原则。

本文首先会介绍本系列文章中用到的示例代码demo的整体结构，然后开始逐一介绍SOLID原则，也即单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。

一个简单的分布式应用系统

本系列示例代码demo获取地址：–Java-

示例代码demo工程实现了一个简单的分布式应用系统（单机版），该系统主要由以下几个模块组成：

示例代码demo工程的主要目录结构如下：

├── db                # 数据库模块，定义Db、Table、TableVisitor等抽象接口 【@单例模式】
│   ├── cache         # 数据库缓存代理，为Db新增缓存功能 【@代理模式】
│   ├── console       # 数据库控制台实现，支持dsl语句查询和结果显示 【@适配器模式】
│   ├── dsl           # 实现数据库dsl语句查询能力，当前只支持select语句查询 【@解释器模式】
│   ├── exception     # 数据库模块相关异常定义
│   ├── iterator      # 遍历表迭代器，包含按序遍历和随机遍历 【@迭代器模式】
│   └── transaction   # 实现数据库的事务功能，包括执行、提交、回滚等 【@命令模式】【@备忘录模式】
├── monitor        # 监控系统模块，采用插件式的架构风格，当前实现access log日志etl功能
│   ├── config     # 监控系统插件配置模块  【@抽象工厂模式】【@组合模式】
│   │   ├── json   # 实现基于json格式文件的配置加载功能
│   │   └── yaml   # 实现基于yaml格式文件的配置加载功能
│   ├── entity     # 监控系统实体对象定义
│   ├── exception  # 监控系统相关异常
│   ├── filter     # Filter插件的实现定义  【@责任链模式】
│   ├── input      # Input插件的实现定义   【@策略模式】
│   ├── output     # Output插件的实现定义
│   ├── pipeline   # Pipeline插件的实现定义，一个pipeline表示一个ETL处理流程 【@桥接模式】
│   ├── plugin     # 插件抽象接口定义
│   └── schema     # 监控系统相关的数据表定义 
├── mq          # 消息队列模块
├── network        # 网络模块，模拟网络通信，定义了socket、packet等通用类型/接口  【@观察者模式】
│   └── http       # 模拟实现了http通信等服务端、客户端能力
├── service           # 服务模块，定义了服务的基本接口
│   ├── mediator      # 服务消息中介，作为服务通信的中转方，实现了服务发现，消息转发的能力 【@中介者模式】
│   ├── registry      # 服务注册中心，提供服务注册、去注册、更新、 发现、订阅、去订阅、通知等功能
│   │   ├── entity    # 服务注册/发现相关的实体定义 【@原型模式】【@建造者模式】
│   │   └── schema    # 服务注册中心相关的数据表定义 【@访问者模式】【@享元模式】
│   └── shopping      # 模拟在线商城服务群的定义，包含订单服务、库存服务、支付服务、发货服务 【@外观模式】
└── sidecar        # 边车模块，对socket进行拦截，提供http access log、流控功能 【@装饰者模式】【@工厂模式】└── flowctrl   # 流控模块，基于消息速率进行随机流控 【@模板方法模式】【@状态模式】

SRP：单一职责原则

单一职责原则（The ，SRP）应该是SOLID原则中，最容易被理解的一个，但同时也是最容易被误解的一个。很多人会把“将大函数重构成一个个职责单一的小函数”这一重构手法等价为SRP，这是不对的，小函数固然体现了职责单一，但这并不是SRP。

SRP传播最广的定义应该是Uncle Bob给出的：

A have one, and only one, to .

也即，一个模块应该有且只有一个导致其变化的原因。

这个解释里有2个需要理解的地方：

（1）如何定义一个模块

我们通常会把一个源文件定义为最小粒度的模块。

（2）如何找到这个原因

一个软件的变化往往是为了满足某个用户的需求，那么这个用户就是导致变化的原因。但是，一个模块的用户/客户端程序往往不只一个，比如Java中的类，它可能会被成千上万的程序使用，但我们不能说职责不单一。因此，我们应该把“一个用户”改为“一类角色”，比如的客户端程序都可以归类为“需要链表/数组功能”的角色。

于是，Uncle Bob给出了SRP的另一个解释：

A be to one, and only one, actor.

有了这个解释，我们就可以理解函数职责单一并不等同于SRP，比如在一个模块有A和B两个函数，它们都是职责单一的，但是函数A的使用者是A类用户，函数B的使用者是B类用户，而且A类用户和B类用户变化的原因都是不一样的，那么这个模块就不满足SRP了。

下面，以我们的分布式应用系统demo为例进一步探讨。对于类（服务注册中心）来说，它对外提供的基本能力有服务注册、更新、去注册和发现功能，那么，我们可以这么实现：

// demo/src/main/java/com/yrunz/designpattern/service/Registry.java
public class Registry implements Service {private final HttpServer httpServer;private final Db db;...@Overridepublic void run() {httpServer.put("/api/v1/service-profile", this::register).post("/api/v1/service-profile", this::update).delete("/api/v1/service-profile", this::deregister).get("/api/v1/service-profile", this::discovery).start();}// 服务注册private HttpResp register(HttpReq req) {...}// 服务更新private HttpResp update(HttpReq req) {...}// 服务去注册private HttpResp deregister(HttpReq req) {...}// 服务发现private HttpResp discovery(HttpReq req) {...}
}

上述实现中，包含了、、、等4个主要方法，正好对应了对外提供的能力，看起来已经是职责单一了。

但是在仔细思考一下就会发现，服务注册、更新和去注册是给专门给服务提供者使用的功能，而服务发现则是专门给服务消费者使用的功能。服务提供者和服务消费者是两类不同的角色，它们产生变化的时间和方向都可能不同。比如：

当前服务发现功能是这么实现的：从满足查询条件的所有中挑选一个返回给服务消费者（也即自己做了负载均衡）。

假设现在服务消费者提出新的需求：把所有满足查询条件的都返回，由服务消费者自己来做负载均衡。

为了实现这样的功能，我们就要修改的代码。按理，服务注册、更新、去注册等功能并不应该受到影响，但因为它们和服务发现功能都在同一个模块（）里，于是被迫也受到影响了，比如可能会代码冲突。

因此，更好的设计是将、、内聚到一个服务管理模块，则放到另一个服务发现模块，服务注册中心再组合和。

具体实现如下：

// demo/src/main/java/com/yrunz/designpattern/service/SvcManagement.java
class SvcManagement {private final Db db;...// 服务注册HttpResp register(HttpReq req) {...}// 服务更新HttpResp update(HttpReq req) {...}// 服务去注册HttpResp deregister(HttpReq req) {...}
}// demo/src/main/java/com/yrunz/designpattern/service/SvcDiscovery.java
class SvcDiscovery {private final Db db;...// 服务发现HttpResp discovery(HttpReq req) {...}
}// demo/src/main/java/com/yrunz/designpattern/service/Registry.java
public class Registry implements Service {private final HttpServer httpServer;private final SvcManagement svcManagement;private final SvcDiscovery svcDiscovery;...@Overridepublic void run() {// 使用子模块的方法完成具体业务httpServer.put("/api/v1/service-profile", svcManagement::register).post("/api/v1/service-profile", svcManagement::update).delete("/api/v1/service-profile", svcManagement::deregister).get("/api/v1/service-profile", svcDiscovery::discovery).start();}
}

除了重复的代码编译，违反SRP还会带来以下2个常见的问题：

1、代码冲突。程序员A修改了模块的A功能，而程序员B在不知情的情况下也在修改该模块的B功能（因为A功能和B功能面向不同的用户，完全可能由2位不同的程序员来维护），当他们同时提交修改时，代码冲突就会发生（修改了同一个源文件）。

2、A功能的修改影响了B功能。如果A功能和B功能都使用了模块里的一个公共函数C，现在A功能有新的需求需要修改函数C，那么如果修改人没有考虑到B功能，那么B功能的原有逻辑就会受到影响。

由此可见，违反SRP会导致软件的可维护性变得极差。但是，我们也不能盲目地进行模块拆分，这样会导致代码过于碎片化，同样也会提升软件的复杂性。比如，在前面的例子中，我们就没有必要再对服务管理模块进行拆分为服务注册模块、服务更新模块和服务去注册模块，一是因为它们面向的用户是一致的；二是在可预见的未来它们要么同时变化，要么都不变。

因此，我们可以得出这样的结论：

如果一个模块面向的都是同一类用户（变化原因一致），那么就没必要进行拆分。如果缺乏用户归类的判断，那么最好的拆分时机是变化发生时。

SRP是聚合和拆分的一个平衡，太过聚合会导致牵一发动全身，拆分过细又会提升复杂性。要从用户的视角来把握拆分的度，把面向不同用户的功能拆分开。如果实在无法判断/预测，那就等变化发生时再拆分，避免过度的设计。

OCP：开闭原则

开闭原则（The Open-Close ，OCP）中，“开”指的是对扩展开放，“闭”指的是对修改封闭，它的完整解释为：

A be open for but for .

通俗地讲就是，一个软件系统应该具备良好的可扩展性，新增功能应当通过扩展的方式实现，而不是在已有的代码基础上修改。

然而，从字面意思上看，OCP貌似又是自相矛盾的：想要给一个模块新增功能，但是又不能修改它。

*如何才能打破这个困境呢？*关键是抽象！优秀的软件系统总是建立在良好的抽象的基础上，抽象化可以降低软件系统的复杂性。

*那么什么是抽象呢？*抽象不仅存在于软件领域，在我们的生活中也随处可见。下面以《语言学的邀请》中的一个例子来解释抽象的含义：

假设某农庄有一头叫“阿花”的母牛，那么：

1、当把它称为“阿花”时，我们看到的是它独一无二的一些特征：身上有很多斑点花纹、额头上还有一个闪电形状的伤疤。

2、当把它称为母牛时，我们忽略了它的独有特征，看到的是它与母牛“阿黑”，母牛“阿黄”的共同点：是一头牛、雌性的。

3、当把它称为家畜时，我们又忽略了它作为母牛的特征，而是看到了它和猪、鸡、羊一样的特点：是一个动物，在农庄里圈养。

4、当把它称为农庄财产时，我们只关注了它和农庄上其他可售对象的共同点：可以卖钱、转让。

从“阿花”，到母牛，到家畜，再到农庄财产，这就是一个不断抽象化的过程。

从上述例子中，我们可以得出这样的结论：

抽象就是不断忽略细节，找到事物间共同点的过程。抽象是分层的，抽象层次越高，细节也就越少。

再回到软件领域，我们也可以把上述的例子类比到数据库上，数据库的抽象层次从低至高可以是这样的：MySQL 8.0版本 -> MySQL -> 关系型数据库 -> 数据库。现在假设有一个需求，需要业务模块将业务数据保存到数据库上，那么就有以下几种设计方案：

我们可以发现，上述方案的演进过程，就是我们不断对业务依赖的数据库模块进行抽象的过程，最终设计出稳定的、服务OCP的软件。

那么，在编程语言中，我们用什么来表示“数据库”这一抽象呢？是接口！

数据库最常见的几个操作就是CRUD，因此我们可以设计这么一个Db接口来表示“数据库”：

public interface Db {Record query(String tableName, Condition cond);void insert(String tableName, Record record);void update(String tableName, Record record);void delete(String tableName, Record record);
}

这样，业务模块和数据库模块之间的依赖关系就变成如下图所示：

满足OCP的另一个关键点就是分离变化，只有先把变化点识别分离出来，我们才能对它进行抽象化。下面以我们的分布式应用系统demo为例，解释如何实现变化点的分离和抽象。

在demo中，监控系统主要负责对服务的 log进行ETL操作，也即涉及如下3个操作：1）从消息队列中获取日志数据；2）对数据进行加工；3）将加工后的数据存储在数据库上。

我们把整一个日志数据的处理流程称为，那么我们可以这么实现：

public class Pipeline implements Plugin {private Mq mq;private Db db;...public void run() {while (!isClose.get()) {// 1、从消息队列中获取数据Message msg = mq.consume("monitor.topic");String accessLog = msg.payload();// 2、对数据进行清理操作，转换为json字符串对格式ObjectNode logJson = new ObjectNode(JsonNodeFactory.instance);logJson.put("content", accessLog);String data = logJson.asText();// 3、存储到数据库上db.insert("logs_table", logId, data);}}...
}

现在考虑新上线一个服务，但是这个服务不支持对接消息队列了，只支持传输数据，于是我们得在上新增一个来判断是否使用输入源：

public class Pipeline implements Plugin {...public void run() {while (!isClose.get()) {String accessLog;// 使用消息队列为消息来源if (inputType == InputType.MQ) {Message msg = mq.consume("monitor.topic");accessLog = msg.payload();}  else {// 使用socket为消息来源Packet packet = socket.receive();accessLog = packet.payload().toString();}...}}
}

过一段时间，有需求需要给 log打上一个时间戳，方便后续的日志分析，于是我们需要修改的数据加工逻辑：

public class Pipeline implements Plugin {...public void run() {while (!isClose.get()) {...// 对数据进行清理操作，转换为json字符串的格式ObjectNode logJson = new ObjectNode(JsonNodeFactory.instance);logJson.put("content", accessLog);// 新增一个时间戳字段logJson.put("timestamp", Instant.now().getEpochSecond());String data = logJson.asText();...}}
}

很快，又有一个需求，需要将加工后的数据存储到ES上，方便后续的日志检索，于是我们再次修改了的数据存储逻辑：

public class Pipeline implements Plugin {...public void run() {while (!isClose.get()) {...// 存储到ES上if (outputType == OutputType.DB) {db.insert("logs_table", logId, data);} else {// 存储到ES上es.store(logId, data)}}}
}

在上述的例子中，每次新增需求都需要修改模块，明显违反了OCP。下面，我们来对它进行优化，使它满足OCP。

第一步是分离变化点，根据的业务处理逻辑，我们可以发现3个独立的变化点，数据的获取、加工和存储。第二步，我们对这3个变化点进行抽象，设计出以下3个抽象接口：

// demo/src/main/java/com/yrunz/designpattern/monitor/input/InputPlugin.java
// 数据获取抽象接口
public interface InputPlugin extends Plugin {Event input();void setContext(Config.Context context);
}// demo/src/main/java/com/yrunz/designpattern/monitor/filter/FilterPlugin.java
// 数据加工抽象接口
public interface FilterPlugin extends Plugin {Event filter(Event event);
}// demo/src/main/java/com/yrunz/designpattern/monitor/output/OutputPlugin.java
// 数据存储抽象接口
public interface OutputPlugin extends Plugin {void output(Event event);void setContext(Config.Context context);
}

最后，的实现如下，只依赖于、和三个抽象接口。后续再有需求变更，只需扩展对应的接口即可，无须再变更：

// demo/src/main/java/com/yrunz/designpattern/monitor/pipeline/Pipeline.java
// ETL流程定义
public class Pipeline implements Plugin {final InputPlugin input;final FilterPlugin filter;final OutputPlugin output;final AtomicBoolean isClose;public Pipeline(InputPlugin input, FilterPlugin filter, OutputPlugin output) {this.input = input;this.filter = filter;this.output = output;this.isClose = new AtomicBoolean(false);}// 运行pipelinepublic void run() {while (!isClose.get()) {Event event = input.input();event = filter.filter(event);output.output(event);}}...
}

OCP是软件设计的终极目标，我们都希望能设计出可以新增功能却不用动老代码的软件。但是100%的对修改封闭肯定是做不到的，另外，遵循OCP的代价也是巨大的。它需要软件设计人员能够根据具体的业务场景识别出那些最有可能变化的点，然后分离出去，抽象成稳定的接口。这要求设计人员必须具备丰富的实战经验，以及非常熟悉该领域的业务场景。否则，盲目地分离变化点、过度地抽象，都会导致软件系统变得更加复杂。

LSP：里氏替换原则

上一节介绍中，OCP的一个关键点就是抽象，而如何判断一个抽象是否合理，这是里氏替换原则（The ，LSP）需要回答的问题。

LSP的最初定义如下：

If for each o1 of type S there is an o2 of type T such that for all P in terms of T, the of P is when o1 is for o2 then S is a of T.

简单地讲就是，子类型必须能够替换掉它们的基类型，也即基类中的所有性质，在子类中仍能成立。一个简单的例子：假设有一个函数f，它的入参类型是基类B。同时，基类B有一个派生类D，如果把D的实例传递给函数f，那么函数f的行为功能应该是不变的。

由此可以看出，违反LSP的后果很严重，会导致程序出现不在预期之内的行为错误。下面，我们看一个经典反面例子，矩形与正方形。

假设现在有矩形，可以通过方法设置宽度，方法设置长度，area方法得到矩形面积：

// 矩形定义
public class Rectangle {private int width; // 宽度private int length; // 长度// 设置宽度public void setWidth(int width) {this.width = width;}// 设置长度public void setLength(int length) {this.length = length;}// 返回矩形面积public int area() {return width * length;}
}

另外，有一个客户端程序Cient，它的方法f以作为入参，逻辑为校验矩形的逻辑：

// 客户端程序
public class Client {// 校验矩形面积为长*宽public void f(Rectangle rectangle) {rectangle.setWidth(5);rectangle.setLength(4);if (rectangle.area() != 20) {throw new RuntimeException("rectangle's area is invalid");}System.out.println("rectangle's area is valid");}
}
// 运行程序
public static void main(String[] args) {Rectangle rectangle = new Rectangle();Client client = new Client();client.f(rectangle);}
// 运行结果：
// rectangle's area is valid

现在，我们打算新增一种新的类型，正方形。因为从数学上看，正方形也是矩形的一种，因此我们让继承了。另外，正方形要求长宽一致，因此重写了和方法：

// 正方形，长宽相等
public class Square extends Rectangle {// 设置宽度public void setWidth(int width) {this.width = width;// 长宽相等，因此同时设置长度this.length = width;}// 设置长度public void setLength(int length) {this.length = length;// 长宽相等，因此同时设置长度this.width = length;}
}

下面，我们把实例化后作为入参传入Cient.f上：

public static void main(String[] args) {Square square = new Square();Client client = new Client();client.f(square);
}
// 运行结果:
// Exception in thread "main" java.lang.RuntimeException: rectangle's area is invalid
// 	at com.yrunz.designpattern.service.mediator.Client.f(Client.java:8)
// 	at com.yrunz.designpattern.service.mediator.Client.main(Client.java:16)

我们发现Cient.f的行为发生了变化，子类型并不能替代基类型，违反了LSP。

出现上面的这种违反LSP的设计，主要原因还是我们孤立地进行模型设计，没有从客户端程序的角度来审视该设计是否正确。我们孤立地认为在数学上成立的关系（正方形 IS-A 矩形），在程序中也一定成立，而忽略了客户端程序的使用方法（先设置宽度为5，长度为4，然后校验面积为20）。

这个例子告诉我们：一个模型的正确性或有效性，只能通过客户端程序来体现。

下面，我们总结一下在继承体系（IS-A）下，要想设计出符合LSP的模型所需要遵循的一些约束：

基类应该设计为一个抽象类（不能直接实例化，只能被继承）。子类应该实现基类的抽象接口，而不是重写基类已经实现的具体方法。子类可以新增功能，但不能改变基类的功能。子类不能新增约束，包括抛出基类没有声明的异常。

前面的矩形和正方形的例子中，几乎把这些约束都打破了，从而导致了程序的异常行为：1）的基类不是一个抽象类，打破约束1；2）重写了基类的和方法，打破约束2；3）新增了没有的约束，长宽相等，打破约束4。

除了继承之外，另一个实现抽象的机制是接口。如果我们是面向接口的设计，那么上述的约束1～3其实已经满足了：1）接口本身不具备实例化能力，满足约束1；2）接口没有具体的实现方法（Java中接口的方法比较例外，本文先不考虑），也就不会被重写，满足约束2；3）接口本身只定义了行为契约，并没有实际的功能，因此也不会被改变，满足约束3。

因此，使用接口替代继承来实现多态和抽象，能够减少很多不经意的错误。但是面向接口设计仍然需要遵循约束4，下面我们以分布式应用系统demo为例，介绍一个比较隐晦地打破约束4，从而违反了LSP的实现。

还是以监控系统为例，为例实现ETL流程的灵活配置，我们需要通过配置文件定义的流程功能（数据从哪获取、需要经过哪些加工、加工后存储到哪里）。当前需要支持json和yaml两种配置文件格式，以yaml配置为例，配置内容是这样的：

# src/main/resources/pipelines/pipeline_0.yaml
name: pipeline_0 # pipeline名称
type: single_thread # pipeline类型
input: # input插件定义（数据从哪里来）name: input_0 # input插件名称type: memory_mq # input插件类型context: # input插件的初始化上下文topic: access_log.topic
filter: # filter插件定义（需要经过哪些加工）- name: filter_0 # 加工流程filter_0定义，类型为log_to_jsontype: log_to_json- name: filter_1 # 加工流程filter_1定义，类型为add_timestamptype: add_timestamp- name: filter_2 # 加工流程filter_2定义，类型为json_to_monitor_eventtype: json_to_monitor_event
output: # output插件定义（加工后存储到哪里）name: output_0 # output插件名称type: memory_db # output插件类型context: # output插件的初始化上下文tableName: monitor_event_0

首先我们定义一个接口来表示“配置”这一抽象:

// demo/src/main/java/com/yrunz/designpattern/monitor/config/Config.java
public interface Config {// 从json字符串中加载配置void load(String conf);
}

另外，上述配置中的input、、子项，可以认为是、、插件的配置项，由插件的配置项组合在一起，因此我们定义了如下几个的抽象类：

// demo/src/main/java/com/yrunz/designpattern/monitor/config/InputConfig.java
public abstract class InputConfig implements Config {protected String name;protected InputType type;protected Context ctx;// 子类实现具体加载逻辑，支持yaml和json的加载方式@Overridepublic abstract void load(String conf);...
}
// demo/src/main/java/com/yrunz/designpattern/monitor/config/FilterConfig.java
public abstract class FilterConfig implements Config {protected List<Item> items;// 子类实现具体加载逻辑，支持yaml和json的加载方式@Overridepublic abstract void load(String conf);...
}
// demo/src/main/java/com/yrunz/designpattern/monitor/config/OutputConfig.java
public abstract class OutputConfig implements Config {protected String name;protected OutputType type;protected Context ctx;// 子类实现具体加载逻辑，支持yaml和json的加载方式@Overrideabstract public void load(String conf);...
}
// demo/src/main/java/com/yrunz/designpattern/monitor/config/PipelineConfig.java
public abstract class PipelineConfig implements Config {protected String name;protected PipelineType type;protected final InputConfig inputConfig;protected final FilterConfig filterConfig;protected final OutputConfig outputConfig;// 子类实现具体加载逻辑，支持yaml和json的加载方式@Overridepublic abstract void load(String conf);
}

最后再实现具体的基于json和yaml的子类：

// json方式加载Config子类目录：src/main/java/com/yrunz/designpattern/monitor/config/json
public class JsonInputConfig extends InputConfig  {...}
public class JsonFilterConfig extends FilterConfig  {...}
public class JsonOutputConfig extends OutputConfig  {...}
public class JsonPipelineConfig extends PipelineConfig  {...}
// yaml方式加载Config子类目录：src/main/java/com/yrunz/designpattern/monitor/config/yaml
public class YamlInputConfig extends InputConfig  {...}
public class YamlFilterConfig extends FilterConfig  {...}
public class YamlOutputConfig extends OutputConfig  {...}
public class YamlPipelineConfig extends PipelineConfig  {...}

因为涉及到从配置到对象的实例化过程，自然会想到使用***工厂模式***来创建对象。另外因为、、和都实现了接口，我们也很容易想到定义一个接口来表示“插件工厂”这一抽象，具体的插件工厂再实现该接口：

// 插件工厂接口，根据配置实例化插件
public interface PluginFactory {Plugin create(Config config);
}
// input插件工厂
public class InputPluginFactory implements PluginFactory {...@Overridepublic InputPlugin create(Config config) {InputConfig conf = (InputConfig) config;try {Class<?> inputClass = Class.forName(conf.type().classPath());InputPlugin input = (InputPlugin) inputClass.getConstructor().newInstance();input.setContext(conf.context());return input;} ...}
}
// filter插件工厂
public class FilterPluginFactory implements PluginFactory {...@Overridepublic FilterPlugin create(Config config) {FilterConfig conf = (FilterConfig) config;FilterChain filterChain = FilterChain.empty();String name = "";try {for (FilterConfig.Item item : conf.items()) {name = item.name();Class<?> filterClass = Class.forName(item.type().classPath());FilterPlugin filter = (FilterPlugin) filterClass.getConstructor().newInstance();filterChain.add(filter);}} ...}
}
// output插件工厂
public class OutputPluginFactory implements PluginFactory {...@Overridepublic OutputPlugin create(Config config) {OutputConfig conf = (OutputConfig) config;try {Class<?> outputClass = Class.forName(conf.type().classPath());OutputPlugin output = (OutputPlugin) outputClass.getConstructor().newInstance();output.setContext(conf.context());return output;} ...}
}
// pipeline插件工厂
public class PipelineFactory implements PluginFactory {...@Overridepublic Pipeline create(Config config) {PipelineConfig conf = (PipelineConfig) config;InputPlugin input = InputPluginFactory.newInstance().create(conf.input());FilterPlugin filter = FilterPluginFactory.newInstance().create(conf.filter());OutputPlugin output = OutputPluginFactory.newInstance().create(conf.output());...}
}

最后，通过来创建对象：

Config config = YamlPipelineConfig.of(YamlInputConfig.empty(), YamlFilterConfig.empty(), YamlOutputConfig.empty());
config.load(Files.readAllBytes("pipeline_0.yaml"));
Pipeline pipeline = PipelineFactory.newInstance().create(config);
assertNotNull(pipeline);
// 运行结果：
Pass

到目前为止，上述的设计看起来是合理的，运行也没有问题。

但是，细心的读者可能会发现，每个插件工厂子类的方法的第一行代码都是一个转型语句，比如的是 conf = () ;。所以，上一段代码能够正常运行的前提是：传入.方法的入参必须是 。如果客户端程序传入的实例，.方法将会抛出转型失败的异常。

上述这个例子就是一个违反LSP的典型场景，虽然在约定好的前提下，程序可以运行正确，但是如果有客户端不小心破坏了这个约定，就会带来程序行为异常（我们永远无法预知客户端的所有行为）。

要纠正这个问题也很简单，就是去掉这一层抽象，让.等工厂方法的入参声明为具体的配置类，比如可以这么实现：

// demo/src/main/java/com/yrunz/designpattern/monitor/pipeline/PipelineFactory.java
// pipeline插件工厂，不再实现PluginFactory接口
public class PipelineFactory {...// 工厂方法入参为PipelineConfig实现类，消除转型public Pipeline create(PipelineConfig config) {InputPlugin input = InputPluginFactory.newInstance().create(config.input());FilterPlugin filter = FilterPluginFactory.newInstance().create(config.filter());OutputPlugin output = OutputPluginFactory.newInstance().create(config.output());...}
}

从上述几个例子中，我们可以看出遵循LSP的重要性，而设计出符合LSP的软件的要点就是，根据该软件的使用者行为作出的合理假设，以此来审视它是否具备有效性和正确性。

ISP：接口隔离原则

接口隔离原则（The ，ISP）是关于接口设计的一项原则，这里的“接口”并不单指Java或Go上使用声明的狭义接口，而是包含了狭义接口、抽象类、具象类等在内的广义接口。它的定义如下：

not be to on it does not use.

也即，一个模块不应该强迫客户程序依赖它们不想使用的接口，模块间的关系应该建立在最小的接口集上。

下面，我们通过一个例子来详细介绍ISP。

上图中，、、都依赖了，但实际上，只需使用.func1方法，只需使用.func2，只需使用.func3，那么这时候我们就可以说该设计违反了ISP。

违反ISP主要会带来如下2个问题：

增加模块与客户端程序的依赖，比如在上述例子中，虽然和都没有调用func1，但是当修改func1还是必须通知～3，因为并不知道它们是否使用了func1。产生接口污染，假设开发的程序员，在写代码时不小心把func1打成了func2，那么就会带来的行为异常。也即被func2给污染了。

为了解决上述2个问题，我们可以把func1、func2、func3通过接口隔离开：

接口隔离之后，只依赖了，而上只有func1一个方法，也即不会受到func2和func3的污染；另外，当修改func1之后，它只需通知依赖了的客户端即可，大大降低了模块间耦合。

实现ISP的关键是将大接口拆分成小接口，而拆分的关键就是接口粒度的把握。想要拆分得好，就要求接口设计人员对业务场景非常熟悉，对接口使用的场景了如指掌。否则孤立地设计接口，很难满足ISP。

下面，我们以分布式应用系统demo为例，来进一步介绍ISP的实现。

一个消息队列模块通常包含生产（）和消费（）两种行为，因此我们设计了Mq消息队列抽象接口，包含和两个方法：

// 消息队列接口
public interface Mq {Message consume(String topic);void produce(Message message);
}// demo/src/main/java/com/yrunz/designpattern/mq/MemoryMq.java
// 当前提供MemoryMq内存消息队列的实现
public class MemoryMq implements Mq {...}

当前demo中使用接口的模块有2个，分别是作为消费者的和作为生产者的：

public class MemoryMqInput implements InputPlugin {private String topic;private Mq mq;...@Overridepublic Event input() {Message message = mq.consume(topic);Map<String, String> header = new HashMap<>();header.put("topic", topic);return Event.of(header, message.payload());}...
}
public class AccessLogSidecar implements Socket {private final Mq mq;private final String topic...@Overridepublic void send(Packet packet) {if ((packet.payload() instanceof HttpReq)) {String log = String.format("[%s][SEND_REQ]send http request to %s",packet.src(), packet.dest());Message message = Message.of(topic, log);mq.produce(message);}...}...
}

从领域模型上看，Mq接口的设计确实没有问题，它就应该包含和两个方法。但是从客户端程序的角度上看，它却违反了ISP，对来说，它只需要方法；对来说，它只需要方法。

一种设计方案是把Mq接口拆分成2个子接口和，让直接实现和：

// demo/src/main/java/com/yrunz/designpattern/mq/Consumable.java
// 消费者接口，从消息队列中消费数据
public interface Consumable {Message consume(String topic);
}// demo/src/main/java/com/yrunz/designpattern/mq/Producible.java
// 生产者接口，向消息队列生产消费数据
public interface Producible {void produce(Message message);
}// 当前提供MemoryMq内存消息队列的实现
public class MemoryMq implements Consumable, Producible {...}

仔细思考一下，就会发现上面的设计不太符合消息队列的领域模型，因为Mq的这个抽象确实应该存在的。

更好的设计应该是保留Mq抽象接口，让Mq继承自和，这样的分层设计之后，既能满足ISP，又能让实现符合消息队列的领域模型：

具体实现如下：

// demo/src/main/java/com/yrunz/designpattern/mq/Mq.java
// 消息队列接口，继承了Consumable和Producible，同时又consume和produce两种行为
public interface Mq extends Consumable, Producible {}// 当前提供MemoryMq内存消息队列的实现
public class MemoryMq implements Mq {...}// demo/src/main/java/com/yrunz/designpattern/monitor/input/MemoryMqInput.java
public class MemoryMqInput implements InputPlugin {private String topic;// 消费者只依赖Consumable接口private Consumable consumer;...@Overridepublic Event input() {Message message = consumer.consume(topic);Map<String, String> header = new HashMap<>();header.put("topic", topic);return Event.of(header, message.payload());}...
}// demo/src/main/java/com/yrunz/designpattern/sidecar/AccessLogSidecar.java
public class AccessLogSidecar implements Socket {// 生产者只依赖Producible接口private final Producible producer;private final String topic...@Overridepublic void send(Packet packet) {if ((packet.payload() instanceof HttpReq)) {String log = String.format("[%s][SEND_REQ]send http request to %s",packet.src(), packet.dest());Message message = Message.of(topic, log);producer.produce(message);}...}...
}

接口隔离可以减少模块间耦合，提升系统稳定性，但是过度地细化和拆分接口，也会导致系统的接口数量的上涨，从而产生更大的维护成本。接口的粒度需要根据具体的业务场景来定，可以参考单一职责原则，将那些为同一类客户端程序提供服务的接口合并在一起。

DIP：依赖倒置原则

《Clean 》中介绍OCP时有提过：如果要模块A免于模块B变化的影响，那么就要模块B依赖于模块A。这句话貌似是矛盾的，模块A需要使用模块B的功能，怎么会让模块B反过来依赖模块A呢？这就是依赖倒置原则（The ，DIP）所要解答的问题。

DIP的定义如下：

High-level not from low-level . Both on . not on . ( ) on .

翻译过来，就是：

1、高层模块不应该依赖低层模块，两者都应该依赖抽象

2、抽象不应该依赖细节，细节应该依赖抽象

在DIP的定义里，出现了高层模块、低层模块、抽象、细节等4个关键字，要弄清楚DIP的含义，理解者4个关键字至关重要。

（1）高层模块和低层模块

一般地，我们认为高层模块是包含了应用程序核心业务逻辑、策略的模块，是整个应用程序的灵魂所在；低层模块通常是一些基础设施，比如数据库、Web框架等，它们主要为了辅助高层模块完成业务而存在。

（2）抽象和细节

在前文“OCP：开闭原则”一节中，我们可以知道，抽象就是众多细节中的共同点，抽象就是不断忽略细节的出来的。

现在再来看DIP的定义，对于第2点我们不难理解，从抽象的定义来看，抽象是不会依赖细节的，否则那就不是抽象了；而细节依赖抽象往往都是成立的。

理解DIP的关键在于第1点，按照我们正向的思维，高层模块要借助低层模块来完成业务，这必然会导致高层模块依赖低层模块。但是在软件领域里，我们可以把这个依赖关系倒置过来，这其中的关键就是抽象。我们可以忽略掉低层模块的细节，抽象出一个稳定的接口，然后让高层模块依赖该接口，同时让低层模块实现该接口，从而实现了依赖关系的倒置：

之所以要把高层模块和底层模块的依赖关系倒置过来，主要是因为作为核心的高层模块不应该受到低层模块变化的影响。高层模块的变化原因应当只能有一个，那就是来自软件用户的业务变更需求。

下面，我们通过分布式应用系统demo来介绍DIP的实现。

对于服务注册中心来说，当有新的服务注册上来时，它需要把服务信息（如服务ID、服务类型等）保存下来，以便在后续的服务发现中能够返回给客户端。因此，需要一个数据库来辅助它完成业务。刚好，我们的数据库模块实现了一个内存数据库，于是我们可以这么实现：

// 服务注册中心
public class Registry implements Service {...// 直接依赖MemoryDbprivate final MemoryDb db;private final SvcManagement svcManagement;private final SvcDiscovery svcDiscovery;private Registry(...) {...// 初始化MemoryDbthis.db = MemoryDb.instance();this.svcManagement = new SvcManagement(localIp, this.db, sidecarFactory);this.svcDiscovery = new SvcDiscovery(this.db);}...
}// 内存数据库
public class MemoryDb {private final Map<String, Table<?, ?>> tables;...// 查询表记录public <PrimaryKey, Record> Optional<Record> query(String tableName, PrimaryKey primaryKey) {Table<PrimaryKey, Record> table = (Table<PrimaryKey, Record>) tableOf(tableName);return table.query(primaryKey);}// 插入表记录public <PrimaryKey, Record> void insert(String tableName, PrimaryKey primaryKey, Record record) {Table<PrimaryKey, Record> table = (Table<PrimaryKey, Record>) tableOf(tableName);table.insert(primaryKey, record);}// 更新表记录public <PrimaryKey, Record> void update(String tableName, PrimaryKey primaryKey, Record record) {Table<PrimaryKey, Record> table = (Table<PrimaryKey, Record>) tableOf(tableName);table.update(primaryKey, record);}// 删除表记录public <PrimaryKey> void delete(String tableName, PrimaryKey primaryKey) {Table<PrimaryKey, ?> table = (Table<PrimaryKey, ?>) tableOf(tableName);table.delete(primaryKey);}...
}

按照上面的设计，模块间的依赖关系是依赖于，也即高层模块依赖于低层模块。这种依赖关系是脆弱的，如果哪天需要把存储服务信息的数据库从改成，那么我们也得改的代码：

// 服务注册中心
public class Registry implements Service {...// 改成依赖DiskDbprivate final DiskDb db;...private Registry(...) {...// 初始化DiskDbthis.db = DiskDb.instance();this.svcManagement = new SvcManagement(localIp, this.db, sidecarFactory);this.svcDiscovery = new SvcDiscovery(this.db);}...
}

更好的设计应该是把和的依赖关系倒置过来，首先我们需要从细节抽象出一个稳定的接口Db：

// demo/src/main/java/com/yrunz/designpattern/db/Db.java
// DB抽象接口
public interface Db {<PrimaryKey, Record> Optional<Record> query(String tableName, PrimaryKey primaryKey);<PrimaryKey, Record> void insert(String tableName, PrimaryKey primaryKey, Record record);<PrimaryKey, Record> void update(String tableName, PrimaryKey primaryKey, Record record);<PrimaryKey> void delete(String tableName, PrimaryKey primaryKey);...
}

接着，我们让依赖Db接口，而实现Db接口，以此来完成依赖倒置：

// demo/src/main/java/com/yrunz/designpattern/service/registry/Registry.java
// 服务注册中心
public class Registry implements Service {...// 只依赖于Db抽象接口private final Db db;private final SvcManagement svcManagement;private final SvcDiscovery svcDiscovery;private Registry(..., Db db) {...// 依赖注入Dbthis.db = db;this.svcManagement = new SvcManagement(localIp, this.db, sidecarFactory);this.svcDiscovery = new SvcDiscovery(this.db);}...
}// demo/src/main/java/com/yrunz/designpattern/db/MemoryDb.java
// 内存数据库，实现Db抽象接口
public class MemoryDb implements Db {private final Map<String, Table<?, ?>> tables;...// 查询表记录@Overridepublic <PrimaryKey, Record> Optional<Record> query(String tableName, PrimaryKey primaryKey) {...}// 插入表记录@Overridepublic <PrimaryKey, Record> void insert(String tableName, PrimaryKey primaryKey, Record record) {...}// 更新表记录@Overridepublic <PrimaryKey, Record> void update(String tableName, PrimaryKey primaryKey, Record record) {...}// 删除表记录@Overridepublic <PrimaryKey> void delete(String tableName, PrimaryKey primaryKey) {...}...
}// demo/src/main/java/com/yrunz/designpattern/Example.java
public class Example {// 在main函数中完成依赖注入public static void main(String[] args) {...// 将MemoryDb.instance()注入到Registry上Registry registry = Registry.of(..., MemoryDb.instance());registry.run();}
}

当高层模块依赖抽象接口时，总得在某个时候，某个地方把实现细节（低层模块）注入到高层模块上。在上述例子中，我们选择在main函数上，在创建对象时，把注入进去。

一般地，我们都会在main/启动函数上完成依赖注入，常见的注入的方式有以下几种：

另外，DIP不仅仅适用于模块/类/接口设计，在架构层面也同样适用，比如DDD的分层架构和Uncle Bob的整洁架构，都是运用了DIP：

当然，DIP并不是说高层模块是只能依赖抽象接口，它的本意应该是依赖稳定的接口/抽象类/具象类。如果一个具象类是稳定的，比如Java中的，那么高层模块依赖它也没有问题；相反，如果一个抽象接口是不稳定的，经常变化，那么高层模块依赖该接口也是违反DIP的，这时候应该思考下接口是否抽象合理。

最后

本文花了很长的篇幅讨论了23种设计模式背后的核心思想 —— SOLID原则，它能指导我们设计出高内聚、低耦合的软件系统。但是它毕竟只是原则，如何落地到实际的工程项目上，还是需要参考成功的实践经验。而这些实践经验正是接下来我们要探讨的设计模式。

学习设计模式最好的方法就是实践，在《实践GoF的23种设计模式》后续的文章，我们将以本文介绍的分布式应用系统demo作为实践示范，介绍23种设计模式的程序结构、适用场景、实现方法、优缺点等，让大家对设计模式有个更深入的理解，能够用对、不滥用设计模式。

参考

Clean , C. (“Uncle Bob”)敏捷软件开发：原则、模式与实践, C. (“Uncle Bob”)使用Go实现GoF的23种设计模式, 元闰子SOLID原则精解之里氏替换原则LSP, 人民副首席码仔