如何开发设计模式、Java开发设计模式

推荐学习

• “23种设计模式知识要点”都没读通过，还有脸说摸不清搞不懂？
• 抖音后端123面开挂，全靠这份啃了58天的「Java进阶核心知识集」

前言

设计模式是我们编程道路上绕不开的一环，用好了设计模式能够让代码拥有良好的维护性、可读性以及扩展性，它仿佛就是“优雅”的代名词，各个框架和库也都能见到它的身影。

正是因为它有种种好处，所以很多人在开发时总想将某个设计模式用到项目中来，然而往往会用得比较别扭。其中一部分原因是业务需求并不太符合所用的设计模式，还有一部分原因就是在Web项目中我们对象都是交由Spring框架的Ioc容器来管理，很多设计模式无法直接套用。那么在真正的项目开发中，我们就需要对设计模式做一个灵活的变通，让其能够和框架结合，在实际开发中发挥出真正的优势。

当项目引入IoC容器后，我们一般是通过依赖注入来使用各个对象，将设计模式和框架结合的关键点就在于此！本文会讲解如何通过依赖注入来完成以下三种设计模式：

由浅入深，让你在了解几个设计模式的同时掌握依赖注入的一些妙用。

实战

单例模式

单例应该是很多人接触的第一个设计模式，相比其他设计模式来说单例的概念非常简单，即在一个进程中，某个类从始至终只有一个实例对象。不过概念就算再简单，还是需要一点编码才能实现，这里对该设计模式就不过多介绍了，咱们直接来看看在实际开发中如何运用该模式。

交由Spring IoC容器管理的对象称之为Bean，每个Bean都有其作用域（scope），这个作用域可以理解为Spring控制Bean生命周期的方式。创建和销毁是生命周期中必不可少的节点，单例模式的重点自然是对象的创建。而Spring创建对象的过程对于我们来说是无感知的，即我们只需配置好Bean，然后通过依赖注入就可以使用对象了：

那这个对象的创建我们该如何控制呢？

其实，Bean默认的作用范围就是单例的，我们无需手写单例。要想验证Bean是否为单例很简单，我们在程序各个地方获取Bean后打印其hashCode就可以看是否为同一个对象了，比如两个不同的类中都注入了UserService：

打印结果会是两个相同的hashCode。

为什么Spring默认会用单例的形式来实例化Bean呢？这自然是因为单例可以节约资源，有很多类是没必要实例化多个对象的。

如果我们就是想每次获取Bean时都创建一个对象呢？我们可以在声明Bean的时候加上@Scope注解来配置其作用域：

这样当你每次获取Bean时都会创建一个实例。

Bean的作用域有以下几种，我们可以根据需求配置，大多数情况下我们用默认的单例就好了：

名称说明singleton默认作用范围。每个IoC容器只创建一个对象实例。prototype被定义为多个对象实例。request限定在HTTP请求的生命周期内。每个HTTP客户端请求都有自己的对象实例。session限定在HttpSession的生命周期内。application限定在ServletContext的生命周期内。websocket限定在WebSocket的生命周期内。

这里要额外注意一点，Bean的单例并不能完全算传统意义上的单例，因为其作用域只能保证在IoC容器内保证只有一个对象实例，但是不能保证一个进程内只有一个对象实例。也就是说，如果你不通过Spring提供的方式获取Bean，而是自己创建了一个对象，此时程序就会有多个对象存在了：

这就是需要变通的地方，Spring可以说在我们日常开发中覆盖了每一个角落，只要自己不故意绕开Spring，那么保证IoC容器内的单例基本就等同于保证了整个程序内的单例。

责任链模式

概念比较简单的单例讲解完后，咱们再来看看责任链模式。

模式讲解

该模式并不复杂：一个请求可以被多个对象处理，这些对象连接成一条链并且沿着这条链传递请求，直到有对象处理它为止。该模式的好处是让请求者和接受者解耦，可以动态增删处理逻辑，让处理对象的职责拥有了非常高的灵活性。我们开发中常用的过滤器Filter和拦截器Interceptor就是运用了责任链模式。

光看介绍只会让人云里雾里，我们直接来看下该模式如何运用。

就拿工作中的请假审批来说，当我们发起一个请假申请的时候，一般会有多个审批者，每个审批者都代表着一个责任节点，都有自己的审批逻辑。我们假设有以下审批者：

组长Leader：只能审批不超过三天的请假；
经理Manger：只能审批不超过七天的请假；
老板Boss：能够审批任意天数。

咱们先定义一个请假审批的对象：

按照传统的写法是接受者收到这个对象后通过条件判断来进行相应的处理：

在客户端模拟审批流程：

打印结果如下：

不难看出Handler类中的代码充满了坏味道！每个责任节点间的耦合度非常高，如果要增删某个节点，就要改动这一大段代码，很不灵活。而且这里演示的审批逻辑还只是打印一句话而已，在真实业务中处理逻辑可比这复杂多了，如果要改动起来简直就是灾难。

这时候我们的责任链模式就派上用场了！我们将每个责任节点封装成独立的对象，然后将这些对象组合起来变成一个链条，并通过统一入口挨个处理。

首先，我们要抽象出责任节点的接口，所有节点都实现该接口：

以Leader节点为例，实现该接口：

然后定义一个专门用来处理这些Handler的链条类：

现在我们来看下使用责任链是怎样执行审批流程的：

打印结果和前面一致。

这样带来的好处是显而易见的，我们可以非常方便地增删责任节点，修改某个责任节点的逻辑也不会影响到其他的节点，每个节点只需关注自己的逻辑。并且责任链是按照固定顺序执行节点，按照自己想要的顺序添加各个对象即可方便地排列顺序。

此外责任链有很多变体，比如像Servlet的Filter执行下一个节点时还需要持有链条的引用：

各责任链除了传递的方式不同，整体的链路逻辑也可以有所不同。

我们刚才演示的是将请求交由某一个节点进行处理，只要有一个处理了，后续就不用处理了。有些责任链目的不是找到某一个节点来处理，而是每个节点都做一些事，相当于一个流水线。

比如像刚才的审批流程，我们可以将逻辑改为一个请假申请需要每一个审批人都同意才算申请通过，Leader同意了后转给Manger审批，Manger同意了后转给Boss审批，只有Boss最终同意了才生效。

形式有多种，其核心概念是将请求对象链式传递，不脱离这一点就都可以算作责任链模式，无需太死守定义。

配合框架

责任链模式中，我们都是自己创建责任节点对象，然后将其添加到责任链条中。在实际开发中这样就会有一个问题，如果我们的责任节点里依赖注入了其它的Bean，那么手动创建对象的话则代表该对象就没有交由Spring管理，那些属性也就不会被依赖注入：

此时我们就必须将各个节点对象也交由Spring来管理，然后通过Spring来获取这些对象实例，再将这些对象实例放置到责任链中。其实这种方式大部分人都接触过，Spring MVC的拦截器Interceptor就是这样使用的：

InterceptorRegistry就相当于链条类了，该对象由Spring MVC传递给我们，好让我们添加拦截器，后续Spring MVC会自行调用责任链，我们无需操心。

别人框架定义的责任链会由框架调用，那我们自定义的责任链该如何调用呢？这里有一个更为简便的方式，那就是将Bean依赖注入到集合中！

我们日常开发时都是使用依赖注入获取单个Bean，这是因为我们声明的接口或者父类通常只需一个实现类就可以搞定业务需求了。而刚才我们自定义的Handler接口下会有多个实现类，此时我们就可以一次性注入多个Bean！咱们现在就来改造一下之前的代码。

首先，将每个Handler实现类加上@Service注解，将其声明为Bean：

然后我们来改造一下我们的链条类，将其也声明为一个Bean，然后直接在成员变量上加上@Autowired注解。既然都通过依赖注入来实现了，那么就无需手动再新增责任节点，所以我们将之前的添加节点的方法给去除：

没错，依赖注入非常强大，不止能够注入单个对象，还可以注入多个！这样一来就非常方便了，我们只需实现Handler接口，将实现类声明为Bean，就会自动被注入到责任链中，我们甚至都不用手动添加。要想执行责任链也特别简单，只需获取HandlerChain然后调用即可：

执行效果如下：

咦，全部都是Boss审批了，为啥前面两个节点没有生效呢？因为我们还没有配置Bean注入到集合中的顺序，我们需要加上@Order注解来控制Bean的装配顺序，数字越小越靠前：

这样我们自定义的责任链模式就完美融入到Spring中了！

策略模式

乘热打铁，我们现在再来讲解一个新的模式！

模式讲解

我们开发中经常碰到这样的需求：需要根据不同的情况执行不同的操作。比如我们购物最常见的邮费，不同的地区、不同的商品邮费都会不同。假设现在需求是这样的：

包邮地区：没有超过10KG的货物免邮，10KG以上8元；

邻近地区：没有超过10KG的货物8元，10KG以上16元；

偏远地区：没有超过10KG的货物16元，10KG以上15KG以下24元， 15KG以上32元。

那我们计算邮费的方法大概是这样的：

这么点邮费规则就写了如此长的代码，要是规则稍微再复杂点简直就更长了。而且如果规则有变，就要对这一大块代码缝缝补补，久而久之代码就会变得非常难以维护。

我们首先想到的优化方式是将每一块的计算封装成方法：

这样确实不错，大部分情况下也能满足需求，可依然不够灵活。

因为这些规则都是写死在我们方法内的，如果调用者想使用自己的规则，或者经常修改规则呢？总不能动不动就修改我们写好的代码吧。要知道邮费计算只是订单价格计算的一个小环节，我们固然可以写好几种规则定式来提供服务，但也得允许别人自定义规则。此时，我们更应该将邮费计算操作高度抽象成一个接口，有不同的计算规则就实现不同的类。不同规则代表不同策略，这种方式就是我们的策略模式！我们来看下具体写法：

首先，封装一个邮费计算接口：

然后，我们将那几个地区规则封装成不同的实现类，拿包邮地区示例：

最后，要应用策略的话我们还需要一个专门类：

这样，调用方既可以使用我们已有的策略，也可以非常方便地修改或自定义策略：

可以看到，简单的逻辑直接使用Lambda表达式就完成了自定义策略，若逻辑复杂的话也可以直接新建一个实现类来完成。

这就是策略模式的魅力所在，允许调用方使用不同的策略来得到不同的结果，以达到最大的灵活性！

尽管好处很多，但策略模式缺点也很明显：

大部分缺点可以配合工厂模式或者反射来解决，但这样又增加了系统的复杂性。那有没有既能弥补缺点又不复杂的方案呢，当然是有的，这就是我接下来要讲解的内容。在策略模式配合Spring框架的同时，也能弥补模式本身的缺点！

配合框架

经过责任链模式咱们就可以发现，其实所谓的配合框架就是将我们的对象交给Spring来管理，然后通过Spring调用Bean即可。策略模式中，咱们每个策略类都是手动实例化的，那咱们要做的第一步毫无疑问就是将这些策略类声明为Bean：

然后我们就要通过Spring获取这些Bean。有人可能会自然联想到，我们还是将这些实现类都注入到一个集合中，然后遍历使用。这确实可以，不过太麻烦了。依赖注入可是非常强大的，不仅能将Bean注入到集合中，还能将其注入到Map中！

来看具体用法：

大声告诉我，清不清爽！简不简洁！优不优雅！

依赖注入能够将Bean注入到Map中，其中Key为Bean的名称，Value为Bean对象，这也就是我前面要在@Service注解上设置值的原因，只有这样才能将让调用方直接通过Map的get方法获取到Bean，继而使用该Bean对象。

我们之前的PostageContext类可以不要了，什么时候想调用某策略，直接在调用处注入Map即可。

通过这种方式，我们不仅让策略模式完全融入到Spring框架中，还完美解决了if、else过多等问题！我们要想新增策略，只需新建一个实现类并将其声明成Bean就行了，原有调用方无需改动一行代码即可生效。

小贴士：如果一个接口或者父类有多个实现类，但我又只想依赖注入单个对象，可以使用@Qualifier("Bean的名称")注解来获取指定的Bean。

总结

本文介绍了三种设计模式，以及各设计模式在Spring框架下是如何运用的！这三种设计模式对应的依赖注入方式如下：

将设计模式和Spring框架配合的关键点就在于，如何将模式中的对象交由Spring管理。这是本文的核心，这一点思考清楚了，各个设计模式才能灵活使用。

作者：RudeCrab

原文链接：