万字详解常用设计模式
本文是博主在工作中对常用设计模式的使用经验总结归纳而来分享给大家。
设计模式一共有23种，本文讲解涉及如下：
责任链模式
模板方法模式
发布订阅模式
策略模式
三大分类
业界一般将设计模式分为三大类：
-
创建型模式：对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。有五种创建型模式，分别是工厂方法模式、抽象工厂模式、单例模式、建造者模式和原型模式。
-
结构型模式：关注于对象的组成以及对象之间的依赖关系，描述如何将类或者对象结合在一起形成更大的结构，就像搭积木，可以通过简单积木的组合形成复杂的、功能更为强大的结构。有七种结构型模式，分别是适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式和享元模式。
-
行为型模式：关注于对象的行为问题，是对在不同的对象之间划分责任和算法的抽象化；不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。有十一种行为型模式，分别是策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式和解释器模式。
六大原则
设计模式遵循了六大原则，也称为SOLID原则：
-
单一职责原则（Single Responsibitity Principle）：一个类应该只有一个发生变化的原因。不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分。
-
开闭原则（Open Close Principle）：一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。
-
里氏替换原则（Liskov Substitution Principle）：所有引用基类的地方必须能透明地使用其子类的对象。任何基类可以出现的地方，子类一定可以出现。里氏替换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
-
接口隔离原则（Interface Segregation Principle）：客户端不应该依赖它不需要的接口。类间的依赖关系应该建立在最小的接口上。每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口要好。
-
依赖倒置原则（Dependence Inversion Principle）：上层模块不应该依赖底层模块，它们都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。面向接口编程，依赖于抽象而不依赖于具体。
-
迪米特法则（Law Of Demter）：只与你的直接朋友交谈，不跟“陌生人”说话。一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
设计模式的好处
-
可以重用设计，减少代码的重复，提高代码的可维护性。
-
可以为设计提供共同的词汇，方便程序员间的交流和理解。
-
可以实现开闭原则，增加新的功能或者修改旧的功能不影响原有的结构。
-
可以让重构系统变得容易，确保开发正确的代码，并降低出错的可能。
-
可以支持变化，为重写其他应用程序提供很好的系统架构。
-
后期可以节省大量时间，提高开发效率。
设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
1. 责任链模式
概述
责任链模式（Chain of Responsibility Pattern）是一种行为型设计模式，它通过将请求的发送者和接收者解耦，使多个对象都有机会处理请求。在这个模式中，请求沿着一个处理链依次传递，直到有一个对象能够处理它为止。
责任链模式的核心思想是将请求的发送者和接收者解耦，使得多个对象都有机会处理请求。在责任链模式中，请求会沿着一个处理链依次传递，每个处理者都有机会处理请求，如果一个处理者不能处理请求，则将请求传递给下一个处理者，直到有一个处理者能够处理它。
责任链模式包含以下几个角色：
-
抽象处理者（Handler）：定义了处理请求的接口，通常包含一个指向下一个处理者的引用，用于将请求传递给下一个处理者。
-
具体处理者（ConcreteHandler）：实现了处理请求的接口，具体处理者可以决定是否处理请求，如果不能处理，则将请求传递给下一个处理者。
-
客户端（Client）：创建处理者对象并组成责任链的结构，负责将请求发送给第一个处理者。
责任链模式类
优缺点
优点：
-
责任链模式可以实现请求的发送者和接收者之间的解耦。发送者只需要将请求发送给第一个处理者，无需关心具体是哪个处理者来处理。这样，系统的灵活性大大增强，可以随时增加或修改处理者的顺序。
-
责任链模式能够避免请求的发送者和接收者之间的紧耦合。每个处理者只需要关心自己负责的请求类型，无需关心其他请求。这样，系统的可维护性也得到了提升。
-
责任链模式可以灵活地动态添加或删除处理者。我们可以根据实际情况来调整责任链的结构，以满足不同的业务需求。
缺点：
-
复杂度会明显提升，如果责任链过长或者处理者之间的关系复杂，可能还会导致性能下降和调试困难。
应用场景
责任链模式在许多不同的应用场景中都有广泛的应用。下面列举了一些常见的应用场景：
-
请求处理链：当一个请求需要经过多个处理步骤或处理者进行处理时，可以使用责任链模式。每个处理者负责一部分逻辑，处理完后可以选择将请求传递给下一个处理者，从而形成一个处理链。
-
日志记录：在日志系统中，可以使用责任链模式来记录日志。不同的处理者可以负责不同级别的日志记录，例如，一个处理者负责记录错误日志，另一个处理者负责记录调试日志，然后按照链式结构传递日志。
-
身份验证和权限检查：在身份验证和权限检查系统中，可以使用责任链模式来验证用户的身份和权限。每个处理者可以检查特定的条件，例如用户名和密码的正确性、账户是否锁定等。如果一个处理者无法通过验证，可以将请求传递给下一个处理者。
-
数据过滤和转换：在数据处理过程中，可以使用责任链模式来进行数据过滤和转换。每个处理者可以根据特定的条件过滤数据或对数据进行转换，然后将处理后的数据传递给下一个处理者。
-
错误处理和异常处理：在错误处理和异常处理系统中，可以使用责任链模式来处理错误和异常。不同的处理者可以处理不同类型的错误或异常，并根据需要将错误或异常传递给下一个处理者进行进一步处理或记录。
Java 代码示例
在 Java 中实现责任链模式有多种方式，包括基于接口、基于抽象类、基于注解等。下面将详细介绍基于接口的常见实现方式。
基于接口的实现方式是通过定义一个处理请求的接口，每个处理者实现这个接口，并在自己的实现中决定是否处理请求和传递请求给下一个处理者。
首先，我们定义一个处理请求的接口 Handler 以及请求入参 Request：
public interface Handler {
void handleRequest(Request request);
}
public class Request {
private String type;
// 省略getter、setter
}
然后，我们创建3个具体的处理者类实现这个接口，在具体处理者类的实现中，首先判断自己是否能够处理请求，如果能够处理，则进行处理；否则将请求传递给下一个处理者。代码如下：
public class ConcreteHandlerA implements Handler {
private Handler successor;
public void setSuccessor(Handler successor) {
this.successor = successor;
}
public void handleRequest(Request request) {
if (request.getType().equals("A")) {
// 处理请求的逻辑
} else if (successor != null) {
successor.handleRequest(request);
}
}
}
public class ConcreteHandlerB implements Handler {
private Handler successor;
public void setSuccessor(Handler successor) {
this.successor = successor;
}
public void handleRequest(Request request) {
if (request.getType().equals("B")) {
// 处理请求的逻辑
} else if (successor != null) {
successor.handleRequest(request);
}
}
}
public class ConcreteHandlerC implements Handler {
private Handler successor;
public void setSuccessor(Handler successor) {
this.successor = successor;
}
public void handleRequest(Request request) {
if (request.getType().equals("C")) {
// 处理请求的逻辑
} else if (successor != null) {
successor.handleRequest(request);
}
}
}
接下来，我们创建一个客户端类 Client，用于创建处理者对象并组成责任链的结构：
public class Client {
public static void main(String[] args) {
Handler handlerA = new ConcreteHandlerA();
Handler handlerB = new ConcreteHandlerB();
Handler handlerC = new ConcreteHandlerC();
handlerA.setSuccessor(handlerB);
handlerB.setSuccessor(handlerC);
// 创建请求并发送给第一个处理者
Request request = new Request("A");
handlerA.handleRequest(request);
}
}
在客户端类中，我们创建了具体的处理者对象，并通过 setSuccessor() 方法将它们组成一个责任链的结构。然后，创建一个请求对象，并将请求发送给第一个处理者。
基于接口的实现方式简单直观，每个处理者只需要实现一个接口即可。但是它的缺点是如果责任链较长，需要创建多个处理者对象，增加了系统的复杂性和资源消耗。下面基于 Spring 框架实现一个高级版的责任链模式。
Spring 代码示例
在实际开发中，一个请求会在多个处理器之间流转，每个处理器都可以处理请求。
假设我们有一个 Spring 框架开发的订单处理系统，订单需要依次经过订单检查、库存处理、支付处理。如果某个处理环节无法处理订单，将会终止处理并返回错误信息，只有每个处理器都完成了请求处理，这个订单才算法下单成功。
首先，我们定义一个订单类 Order：
@Data
@AllArgsConstructor
public class orderNo {
private String orderNumber;
private String paymentMethod;
private boolean stockAvailability;
private String shippingAddress;
}
然后，我们定义一个抽象订单处理者类 OrderHandler：
public abstract class OrderHandler {
public abstract void handleOrder(Order order);
}
接下来，我们创建具体的订单处理者类继承自抽象订单处理者类，实现相应的方法，并注册到 Spring 中，
@Component
public class CheckOrderHandler extends OrderHandler {
public void handleOrder(Order order) {
if (StringUtils.isBlank(order.getOrderNo())) {
throw new RuntimeException("订单编号不能为空");
}
if (order.getPrice().compareTo(BigDecimal.ONE) <= 0) {
throw new RuntimeException("订单金额不能小于等于0");
}
if (StringUtils.isBlank(order.getShippingAddress())) {
throw new RuntimeException("收货地址不能为空");
}
System.out.println("订单参数检验通过");
}
}
@Component
public class StockHandler extends OrderHandler {
public void handleOrder(Order order) {
if (!order.isStockAvailability()) {
throw new RuntimeException("订单库存不足");
}
System.out.println("库存扣减成功");
}
}
@Component
public class AliPaymentHandler extends OrderHandler {
public void handleOrder(Order order) {
if (!order.getPaymentMethod().equals("支付宝")) {
throw new RuntimeException("不支持支付宝以外的支付方式");
}
System.out.println("支付宝预下单成功");
}
}
在具体订单处理者类的实现中，CheckOrderHandler 负责做订单参数检查、StockHandler 负责做库存扣减、AliPaymentHandler 负责做预下单，每个处理者的逻辑都是相互独立各不不干扰。
最后，我们创建一个订单生产链条 BuildOrderChain ，用于组成责任链的链条处理结构：
@Component
public class BuildOrderChain {
@Autowired
private AliPaymentHandler aliPaymentHandler;
@Autowired
private CheckOrderHandler checkOrderHandler;
@Autowired
private StockHandler stockHandler;
List list = new ArrayList<>();
@PostConstruct
public void init() {
// 1. 检查订单参数
list.add(checkOrderHandler);
// 2. 扣减库存
list.add(stockHandler);
// 3. 支付宝预下单
list.add(aliPaymentHandler);
}
public void doFilter(Order order) {
for (OrderHandler orderHandler : this.list) {
orderHandler.handleOrder(order);
}
}
}
订单生产链条 BuildOrderChain 类中，我们通过 @PostConstruct 注解下的 init() 初始化方法，将具体的订单处理者按代码顺序组成一个责任链的结构。然后通过 doFilter(order) 方法遍历处理者集合依次处理。
运行代码：
@Slf4j
@SpringBootTest
@RunWith(SpringRunner.class)
public class OrderChainTest {
@Autowired
private BuildOrderChain buildOrderChain;
@Test
public void test() {
Order order = new Order("123456", "支付宝",
true, "长沙", new BigDecimal("100"));
buildOrderChain.doFilter(order);
}
}
-------------------------------
订单参数检验通过
库存扣减成功
支付宝预下单成功
可以看到订单依次经过校验处理器、库存处理器和支付处理器进行处理，直到最后完成整个订单的处理。
在举个例子，假如我们的订单针对的是虚拟不限库存商品，我们不需要进行库存扣减，那我们可以直接新建 VirtualGoodsOrderChain 虚拟商品订单生产链条类，代码如下，
@Component
public class VirtualGoodsOrderChain {
@Autowired
private AliPaymentHandler aliPaymentHandler;
@Autowired
private CheckOrderHandler checkOrderHandler;
List list = new ArrayList<>();
@PostConstruct
public void init() {
// 1. 检查订单参数
list.add(checkOrderHandler);
// 2 支付宝预下单
list.add(aliPaymentHandler);
}
public void doFilter(Order order) {
for (OrderHandler orderHandler : this.list) {
orderHandler.handleOrder(order);
}
}
}
运行代码：
@Test
public void virtualOrderTest() {
Order order = new Order("123456", "支付宝", true, "长沙", new BigDecimal("100"));
virtualGoodsOrderChain.doFilter(order);
}
-------------------------------------------
订单参数检验通过
支付宝预下单成功
总的来说，责任链模式适用于存在多个处理步骤、每个处理步骤具有独立逻辑或条件、需要灵活组合和扩展的场景。通过责任链模式，可以将复杂的处理逻辑拆分为多个独立的处理步骤，并且可以动态地组合和调整处理步骤的顺序，从而提高系统的灵活性和可维护性。希望本文能够帮助读者理解和应用责任链模式，提升软件设计和开发的能力。
2. 模板方法模式
概述
模板方法模式是一种行为型设计模式，它定义一个操作（模板方法）的基本组合与控制流程，将一些步骤（抽象方法）推迟到子类中，在使用时调用不同的子类，就可以达到不改变一个操作的基本流程情况下，即可修改其中的某些特定步骤。这种设计方式将特定步骤的具体实现与操作流程分离开来，实现了代码的复用和扩展，从而提高代码质量和可维护性。
模板方法模式包含以下：
-
抽象类：负责定义模板方法、基本方法、抽象方法。
-
模板方法：在抽象类中定义的流程操作集合，里面有一系列流程操作和条件控制，包含基本方法和抽象方法。
-
基本方法：在抽象类中已经实现了的方法。
-
抽象方法：在抽象类中还没有实现的方法。
-
具体子类：实现抽象类中所定义的抽象方法，也就是实现特定步骤。
模板方法模式
优缺点
-
封装不变部分，扩展可变部分。模板方法模式将可变的部分封装在抽象方法中，不变的部分封装在基本方法中。这使得子类可以根据需求对可变部分进行扩展，而不变部分仍然保持不变。
-
避免重复代码，抽象类中包含的基本方法可以避免子类重复实现相同的代码逻辑。
-
更好的扩展性，由于具体实现由子类来完成，因此可以方便地扩展新的功能或变更实现方式，同时不影响模板方法本身。
模板方法模式的缺点：
-
类多，由于每个算法都需要一个抽象类和具体子类来实现，因此在操作流程比较多时可能导致类的数量急剧增加，从而导致代码的复杂性提高。
-
关联性高，模板方法与子类实现的抽象方法紧密相关，如果该模板方法需要修改，可能会涉及到多个子类的修改。
应用场景
-
开发框架，通常框架会定义一些通用的模板，子类可以根据自身的特定需求来细化模板的实现细节，比如
Spring中的JdbcTemplate、RestTemplate、RabbitTemplate、KafkaTemplate等。 -
业务逻辑，我们可以针对业务流程做一些拆解，将特定步骤改为子类实现。比如发送验证码的流程，在发送验证码时需要选择不同厂商来发送验证码，但是我们发送的验证码前的检查、验证码生成、保存验证码逻辑都是一样的。
Java 代码示例
如上，我们用一个简单的发送短信代码来做模板方法模式的示例：
定义一个发送短信模板
/**
* 发送短信模板
*/
public abstract class SmsTemplate {
/**
* 发送方法
*
* @param mobile 手机号
*/
public void send(String mobile) throws Exception {
System.out.println("检查用户一分钟内是否发送过短信，
mobile:" + mobile);
if (checkUserReceiveInOneMinute(mobile)) {
throw new Exception("请等待1分钟后重试");
}
String code = genCode();
if (manufacturer(mobile, code)) {
System.out.println("短信厂商发送短信成功，
mobile:" + mobile + ",code=" + code);
save2redis(mobile, code);
}
}
/**
* 模板方法，由不同的厂商来实现发送短信到手机上
* @return
*/
abstract boolean manufacturer(String mobile, String code);
/**
* 检查1分钟内该手机号是否接收过验证码，1分钟内接收过就不能在发送验证码
* @param mobile
* @return
*/
public boolean checkUserReceiveInOneMinute(String mobile) {
return ...;
}
/**
* 生成6位验证码
* @return
*/
public String genCode() {
return "123456";
}
/**
* 将手机号+验证码存进redis中，给登录接口做校验用
* @param mobile
* @param code
*/
public void save2redis(String mobile, String code) {
...
}
}
添加两个不同厂商实现的子类
/**
* 阿里云短信发送
*/
public class AliyunSmsSend extends SmsTemplate{
@Override
boolean manufacturer(String mobile, String code) {
System.out.println("读取阿里云短信配置");
System.out.println("创建阿里云发送短信客户端");
System.out.println("阿里云发送短信成功");
return true;
}
}
/**
* 腾讯云短信发送
*/
public class TencentSmsSend extends SmsTemplate {
@Override
boolean manufacturer(String mobile, String code) {
System.out.println("读取腾讯云短信配置");
System.out.println("创建腾讯云发送短信客户端");
System.out.println("腾讯云发送短信成功");
return true;
}
}
在 Java 程序中进行调用
public class Main {
public static void main(String[] args) throws Exception {
SmsTemplate smsTemplate1 = new AliyunSmsSend();
smsTemplate1.send("13333333333");
System.out.println("---------------------------");
SmsTemplate smsTemplate2 = new TencentSmsSend();
smsTemplate2.send("13333333333");
}
}
输出如下：
检查用户一分钟内是否发送过短信，mobile:13333333333
读取阿里云短信配置
创建阿里云发送短信客户端
阿里云发送短信成功
短信厂商发送短信成功，mobile:13333333333,code=123456
---------------------------
检查用户一分钟内是否发送过短信，mobile:13333333333
读取腾讯云短信配置
创建腾讯云发送短信客户端
腾讯云发送短信成功
短信厂商发送短信成功，mobile:13333333333,code=123456
我们来看看模板方法模式的组成：
- 抽象类
SmsTemplate中定义了发送短信的基本流程操作-
发送前检查用户1分钟内是否接收过短信，不变部分。
-
生成验证码，不变部分。
-
发远验证码到用户手机，这个抽象方法由不同子类实现，可变部分。
-
发送成功则保存到 redis 中，不变部分。
-
-
具体子类
AliyunSmsSend、TencentSmsSend继承抽象类，实现抽象方法manufacturer(String mobile, String code)，定义流程中的可变部分。 -
调用模板方法
send(mobile)，在模板方法中完成了基本流程组合与条件控制。
Spring 代码示例
在 Spring 中实现模板方法模式，是非常简单的，我们只需要对上述的 Java 代码示例的 AliyunSmsSend 类稍作改造，加上 @Component 注解就行，
/**
* 阿里云短信发送
*/
@Component
public class AliyunSmsSend extends SmsTemplate{
@Override
boolean manufacturer(String mobile, String code) {
IUserService userService = SpringUtil.getBean(IUserService.class);
System.out.println("读取阿里云短信配置");
System.out.println("创建阿里云发送短信客户端");
System.out.println("阿里云发送短信成功");
return true;
}
}
如果在 AliyunSmsSend 类中需要注入其他 bean，通过 cn.hutool.extra.spring.SpringUtil.getBean(...) 方法获取对应 bean 就行。
使用 Lambda 表达式
在Java8 中，还可以使用函数表达式来替换抽象方法，代码如下，
/**
* 发送短信模板
*/
public class SmsTemplateLambda {
/**
* 发送短信
* @param mobile 手机号
* @param biFunction
* @throws Exception
*/
public void send(String mobile,
BiFunction biFunction) throws Exception {
System.out.println("检查用户一分钟内是否发送过短信，mobile:" + mobile);
if (checkUserReceiveInOneMinute(mobile)) {
throw new Exception("请等待1分钟后重试");
}
String code = genCode();
if (biFunction.apply(mobile, code)) {
System.out.println("短信厂商发送短信成功，mobile:"
+ mobile + ",code=" + code);
save2redis(mobile, code);
}
}
...
}
通过 BiFunction 函数，将不同厂商发送短信到用户手机的代码在 send(mobile) 方法中分离处理。
调用方法如下：
public static void main(String[] args) throws Exception {
SmsTemplateLambda smsTemplateLambda = new SmsTemplateLambda();
smsTemplateLambda.send("1333333333", (s, s2) -> {
System.out.println("读取阿里云短信配置");
System.out.println("创建阿里云发送短信客户端");
System.out.println("阿里云发送短信成功");
return true;
});
smsTemplateLambda.send("1333333333", (s, s2) -> {
System.out.println("读取腾讯云短信配置");
System.out.println("创建腾讯云发送短信客户端");
System.out.println("腾讯云发送短信成功");
return true;
});
}
可以看到，我们可以只在调用 SmsTemplateLambda 类的 send(mobile) 方法时，才实现不同厂商发送短信到手机的具体逻辑。好处就是每增加一个模板方法时，不用增加具体的子类实现，减少类的创建与降低子类的实现成本。
模板方法模式通过定义一个流程基本操作也就是模板方法，将具体的实现步骤推迟到子类中，使得子类可以灵活地实现可变的行为，这是模板方法模式的核心思想与价值所在。
3. 订阅发布模式
概述
订阅发布模式（Publish-Subscribe Pattern）是一种行之有效的解耦框架与业务逻辑的方式，也是一种常见的观察者设计模式，它被广泛应用于事件驱动架构中。
观察者模式的各角色定义如下。
-
Subject（目标主题）：被观察的目标主题的接口抽象，维护观察者对象列表，并定义注册方法register()（订阅）与通知方法notify()（发布）。对应本章例程中的商店类Shop。
-
ConcreteSubject（主题实现）：被观察的目标主题的具体实现类，持有一个属性状态State，可以有多种实现。对应本章例程中的商店类Shop。
-
Observer（观察者）：观察者的接口抽象，定义响应方法update()。对应本章例程中的买家类Buyer。
-
ConcreteObserver（观察者实现）：观察者的具体实现类，可以有任意多个子类实现。实现了响应方法update()，收到通知后进行自己独特的处理。对应本章例程中的手机买家类PhoneFans、海淘买家类HandChopper
订阅发布模式
优缺点
优点：
-
解耦：发布者和订阅者不直接依赖，通过消息代理间接通信，实现解耦。
-
扩展性好：发布者和订阅者可以随时增加或删除，消息类别也可以增加，程序的扩展性很好。
-
松散耦合：发布者无需了解所有的订阅者，只管发布消息；订阅者也无需了解所有的发布者，只关注自己感兴趣的消息。
-
增加新的消息与订阅者很方便:消息中心统一管理消息与订阅者的对应关系，增加新消息时，无需修改已有模块。
缺点:
-
复杂性提高：需要引入消息代理和消息分类这两个新的组件，系统结构变得复杂。
-
性能开销：使用消息代理中转消息，会产生额外的性能开销，如网络交互等。
-
依赖中间件：消息代理的可用性会影响系统的可用性，引入了新的依赖点。
-
难以跟踪数据流向：消息在各个组件之间转发，如果系统比较复杂，消息流向会变得不太清晰。
-
不支持同步操作：发布订阅模式以异步消息通知为基础，不适用于同步操作场景。
应用场景
-
构建实时消息系统：比如普通的即时聊天，群聊等功能。发布者可以将消息发送到指定的频道或者主题，订阅者可以根据自己的兴趣或者身份来订阅不同的频道或者主题，并及时收到消息。
-
实现事件驱动的系统：比如前端框架中的事件监听和触发，或者后端框架中的中间件机制。发布者可以将事件作为消息发送出去，订阅者可以根据自己的业务逻辑来订阅不同的事件，并在事件发生时执行相应的操作。
-
实现分布式系统中的消息队列：比如使用 Redis、RabbitMQ、Kafka 等中间件来实现生产者和消费者之间的通信。发布者可以将任务或者数据作为消息发送到队列中，订阅者可以从队列中获取消息并进行处理。
-
实现微信公众号等推送服务：比如用户可以关注不同的公众号或者主题，并在有新内容时收到推送通知。发布者可以将内容作为消息发送到指定的公众号或者主题，订阅者可以根据自己的喜好来订阅不同的公众号或者主题，并在有新内容时收到推送通知。
Java 代码示例
-
创建订阅者接口，用于接受消息通知。
interface Subscriber {
void update(String message);
}
-
创建发布者，用于发布消息。实现了增加、删除和发布的功能，并且维护了一个订阅列表，
class Publisher {
private Map> subscribers = new HashMap<>();
public void subscribe(String topic, Subscriber subscriber) {
List subscriberList = subscribers.get(topic);
if (subscriberList == null) {
subscriberList = new ArrayList<>();
subscribers.put(topic, subscriberList);
}
subscriberList.add(subscriber);
}
public void unsubscribe(String topic, Subscriber subscriber) {
List subscriberList = subscribers.get(topic);
if (subscriberList != null) {
subscriberList.remove(subscriber);
}
}
public void publish(String topic, String message) {
List subscriberList = subscribers.get(topic);
if (subscriberList != null) {
for (Subscriber subscriber : subscriberList) {
subscriber.update(message);
}
}
}
}
-
我们还实现了两个不同的 Subscriber 实现，一个是 EmailSubscriber，另一个是 SMSSubscriber，用于接受发布者的消息并将其分别发送到邮箱和手机上。
class EmailSubscriber implements Subscriber {
private String email;
public EmailSubscriber(String email) {
this.email = email;
}
public void update(String message) {
System.out.println("Send email to " + email + ": " + message);
}
}
class SMSSubscriber implements Subscriber {
private String phoneNumber;
public SMSSubscriber(String phoneNumber) {
this.phoneNumber = phoneNumber;
}
public void update(String message) {
System.out.println("Send SMS to " + phoneNumber + ": " + message);
}
}
-
在 Main 类中，我们创建了一个 Publisher 对象，并添加了两个 EmailSubscriber 和两个 SMSSubscriber，分别订阅了 news 主题的更新。我们先给这个主题发送一条消息，然后取消 news 主题的其中一个订阅者，最后我们再次给 news 主题发送一条消息。
public class Main {
public static void main(String[] args) {
Publisher publisher = new Publisher();
Subscriber emailSubscriber1 = new EmailSubscriber("[email protected]");
Subscriber smsSubscriber1 = new SMSSubscriber("1234567890");
publisher.subscribe("news", emailSubscriber1);
publisher.subscribe("news", smsSubscriber1);
publisher.publish("news", "发布新消息1");
publisher.unsubscribe("news", smsSubscriber1);
publisher.publish("news", "发布新消息2");
}
}
打印输出如下：
Send email to [email protected]: 发布新消息1
Send SMS to 1234567890: 发布新消息1
Send email to [email protected]: 发布新消息2
Spring 代码示例
Spring的订阅发布模式是通过发布事件、事件监听器和事件发布器3个部分来完成的
这里我们通过 newbee-mall-pro 项目中已经实现订阅发布模式的下单流程给大家讲解，项目地址：GitHub - wayn111/newbee-mall-pro: newbee-mall-pro是newbee-mall商城的pro版本实现了推荐系统、生产可用的秒杀、优惠卷专区，滑块验证码，支付宝支付，中文分词检索等高级功能
-
自定义订单发布事件，继承 ApplicationEvent
public class OrderEvent extends ApplicationEvent {
void onApplicationEvent(Object event) {
...
}
}
-
定义订单监听器，实现 ApplicationListener
@Component
public class OrderListener implements ApplicationListener {
@Override
public void onApplicationEvent(OrderEvent event) {
// 生成订单、删除购物车、扣减库存
...
}
}
-
下单流程，通过事件发布器 applicationEventPublisher 发布订单事件，然后再订单监听器中处理订单保存逻辑。
@Resource
private ApplicationEventPublisher applicationEventPublisher;
private void saveOrder(MallUserVO mallUserVO, Long couponUserId, List shopcatVOList, String orderNo) {
// 订单检查
...
// 生成订单号
String orderNo = NumberUtil.genOrderNo();
// 发布订单事件，在事件监听中处理下单逻辑
applicationEventPublisher.publishEvent(new OrderEvent(orderNo, mallUserVO, couponUserId, shopcatVOList));
// 所有操作成功后，将订单号返回
return orderNo;
...
}
通过事件监听机制，我们将下单逻辑拆分成如下步骤：
-
订单检查
-
生成订单号
-
发布订单事件，在事件监听中处理订单保存逻辑
-
所有操作成功后，将订单号返回
每个步骤都是各自独立
如上的代码已经实现了订阅发布模式，成功解耦了下单逻辑。建议大家在日常开发中多加思考哪些业务流程可以适用，例如微服务项目中订单支付成功后需要通知用户、商品、活动等多个服务时，可以考虑使用订阅发布模式。解耦发布者和订阅者，发布者只管发布消息，不需要知道有哪些订阅者，也不需要知道订阅者的具体实现。订阅者只需要关注自己感兴趣的消息即可。这种松耦合的设计使得系统更容易扩展和维护。
4. 策略模式
概述
策略模式（Strategy Pattern）是一种行为型设计模式，它定义了一组同类型的算法，在不同的类中封装起来，每种算法可以根据当前场景相互替换，从而使算法的变化独立于使用它们的客户端（即算法的调用者）。
策略模式的各角色定义如下。
-
Strategy（策略接口）：定义通用的策略规范标准，包含在系统环境中并声明策略接口标准。对应本章例程中的USB接口USB。
-
ConcreteStrategyA、ConcreteStrategyB、ConcreteStrategyC……（策略实现）：实现了策略接口的策略实现类，可以有多种不同的策略实现，但都得符合策略接口定义的规范。对应本章例程中的USB键盘类Keyboard、USB鼠标类Mouse、USB摄像头类Camera。
-
Context（上下文）：包含策略接口的系统环境，对外提供更换策略实现的方法setStrategy()以及执行策略的方法executeStrategy()，其本身并不关心执行的是哪种策略实现。对应本章例程中的计算机主机类Computer。
策略模式
优缺点
优点：
-
可以避免使用多重条件语句，提高代码的可读性和可维护性。
-
可以提供多种可重用的算法族，减少代码的重复。
-
可以实现开闭原则，增加新的算法或者修改旧的算法不影响原有的结构。
-
可以灵活地切换不同的算法，增加系统的灵活性。
缺点：
-
客户端必须知道所有的策略类，并自行决定使用哪一个策略类，这增加了客户端的复杂度。
-
策略模式会产生很多的策略类，增加系统的类数量。
应用场景
策略模式适用于以下场景：
-
一个系统有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
-
一个系统需要动态地在几种算法中选择一种。
-
如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
Java代码示例
假设我们有一个计算器程序，它可以根据用户输入的不同运算符（+、-、*、/）来执行不同的算术运算。我们可以使用策略模式来实现这个功能，具体步骤如下：
1. 定义一个策略接口
我们首先定义一个策略接口 Strategy ，它声明了一个 doOperation 方法，用于执行具体的运算。
// 策略接口
public interface Strategy {
// 执行运算
public int doOperation(int num1, int num2);
}
2. 实现具体的策略类
然后我们实现四个具体的策略类，分别是 AddStrategy 、SubtractStrategy 、MultiplyStrategy 和 DivideStrategy ，它们都实现了 Strategy 接口，并重写了 doOperation 方法。
// 加法策略
public class AddStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 + num2;
}
}
// 减法策略
public class SubtractStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 - num2;
}
}
// 乘法策略
public class MultiplyStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 * num2;
}
}
// 除法策略
public class DivideStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
if (num2 == 0) {
throw new IllegalArgumentException("除数不能为0");
}
return num1 / num2;
}
}
3. 定义一个上下文类
接下来我们定义一个上下文类 Context ，它持有一个 Strategy 的引用，并提供了一个构造方法和一个 executeStrategy 方法。构造方法用于传入具体的策略对象，executeStrategy 方法用于调用策略对象的 doOperation 方法。
// 上下文类
public class Context {
private Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
public int executeStrategy(int num1, int num2) {
return strategy.doOperation(num1, num2);
}
}
4. 测试策略模式
最后我们编写一个测试类，用于创建不同的策略对象和上下文对象，并根据用户的输入来执行不同的算法。
// 测试类
public class StrategyTest {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.println("请输入第一个数：");
int num1 = scanner.nextInt();
System.out.println("请输入运算符（+、-、*、/）：");
String operator = scanner.next();
System.out.println("请输入第二个数：");
int num2 = scanner.nextInt();
scanner.close();
// 根据运算符创建不同的策略对象
Strategy strategy;
switch (operator) {
case "+" -> strategy = new AddStrategy();
case "-" -> strategy = new SubtractStrategy();
case "*" -> strategy = new MultiplyStrategy();
case "/" -> strategy = new DivideStrategy();
default -> {
System.out.println("无效的运算符");
return;
}
}
// 创建上下文对象，并传入策略对象
Context context = new Context(strategy);
// 调用上下文对象的方法，执行策略对象的算法
int result = context.executeStrategy(num1, num2);
// 输出结果
System.out.println(num1 + " " + operator + " " + num2 + " = " + result);
}
}
运行结果：
请输入第一个数：
1
请输入运算符（+、-、*、/）：
+
请输入第二个数：
1
1 + 1 = 2
Spring 代码示例
在 Spring 框架中，也有很多地方使用了策略模式，比如 BeanFactory 的实现类，它们都实现了一个 BeanFactory 接口，但是具体的实例化和管理 Bean 的方式不同。比如 XmlBeanFactory 是从 XML 文件中读取 Bean 的定义，而 AnnotationConfigApplicationContext 是从注解中读取 Bean 的定义。
我们可以使用 Spring 的依赖注入功能，来实现策略模式，具体步骤如下：
1. 定义一个策略接口
我们还是使用上面的计算器程序作为例子，首先定义一个策略接口 Strategy ，它声明了一个 doOperation 方法，用于执行具体的运算。
// 策略接口
public interface Strategy {
// 执行运算
public int doOperation(int num1, int num2);
}
2. 实现具体的策略类
然后我们实现四个具体的策略类，分别是 AddStrategy 、SubtractStrategy 、MultiplyStrategy 和 DivideStrategy ，它们都实现了 Strategy 接口，并重写了 doOperation 方法。同时，我们给每个策略类添加一个 @Component 注解，表示它们是 Spring 容器管理的组件。
// 加法策略
@Component
public class AddStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 + num2;
}
}
// 减法策略
@Component
public class SubtractStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 - num2;
}
}
// 乘法策略
@Component
public class MultiplyStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
return num1 * num2;
}
}
// 除法策略
@Component
public class DivideStrategy implements Strategy {
@Override
public int doOperation(int num1, int num2) {
if (num2 == 0) {
throw new IllegalArgumentException("除数不能为0");
}
return num1;
}
}
好的，我继续写。
3. 定义一个上下文类
接下来我们定义一个上下文类 Context ，它持有一个 Strategy 的引用，并提供了一个构造方法和一个 executeStrategy 方法。构造方法用于传入具体的策略对象，executeStrategy 方法用于调用策略对象的 doOperation 方法。同时，我们给上下文类添加一个 @Component 注解，表示它也是 Spring 容器管理的组件。
// 上下文类
@Component
public class Context {
private Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
public int executeStrategy(int num1, int num2) {
return strategy.doOperation(num1, num2);
}
}
4. 使用 @Autowired 注入策略对象
为了让 Spring 容器能够自动注入不同的策略对象，我们需要使用 @Autowired 注解来标注 Context 类的构造方法，并使用 @Qualifier 注解来指定具体的策略类。这样，我们就可以根据不同的运算符来创建不同的上下文对象，而不需要手动创建策略对象。
// 上下文类
@Component
public class Context {
@Autowired
private List list;
public Strategy getBean(Class tClass) throws Exception {
for (Strategy strategy : list) {
if (strategy.getClass() == tClass) {
return strategy;
}
}
throw new Exception("获取策略失败");
}
}
5. 测试策略模式
最后我们编写一个测试类，用于从 Spring 容器中获取 Context 对象，并根据用户的输入来执行不同的算法。
// 测试类
@SpringBootTest
@RunWith(SpringRunner.class)
public class StrategyTest {
// 从Spring容器中获取Context对象
@Autowired
private Context context;
@Test
public void test() throws Exception {
System.out.println("请输入第一个数：2");
int num1 = 2;
System.out.println("请输入运算符（+、-、*、/）：*");
String operator = "*";
System.out.println("请输入第二个数：3");
int num2 = 3;
// 根据运算符创建不同的上下文对象
Strategy strategy;
switch (operator) {
case "+" -> strategy = context.getBean(AddStrategy.class);
case "-" -> strategy = context.getBean(SubtractStrategy.class);
case "*" -> strategy = context.getBean(MultiplyStrategy.class);
case "/" -> strategy = context.getBean(DivideStrategy.class);
default -> {
System.out.println("无效的运算符");
return;
}
}
// 调用上下文对象的方法，执行策略对象的算法
int result = strategy.doOperation(num1, num2);
// 输出结果
System.out.println(num1 + " " + operator + " " + num2 + " = " + result);
}
}
运行结果：
请输入第一个数：2
请输入运算符（+、-、*、/）：*
请输入第二个数：3
2 * 3 = 6
总的来说策略模式是一种常用的行为型设计模式，它可以将不同的算法封装在不同的类中，并让它们可以相互替换。策略模式可以避免使用多重条件语句，提高代码的可读性和可维护性，同时也可以实现开闭原则，增加系统的灵活性。但是策略模式也会增加客户端和系统的复杂度，因此需要根据具体的情况来权衡利弊。
总结
至此本文所讲的四种常用设计模式就全部介绍完了，希望能对大家有所帮助。
关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、高效开发工具等，你的关注将是我的更新动力！