设计模式在项目中的应用（持续更新）

目前设计模式的介绍已经很多，自己也有一定的了解，但是在代码落地中不够，与业务的结合还比较欠缺。

那通过这篇文章记录下：在思考特定的设计模式的时候，如何恰如其分的与我们的业务结合起来，并进行落地。

我觉得要思考到这一点，或这个层面的话，也是需要对业务有很深的理解，然后对具体的某个设计模式有深刻的认识，才能将他们结合起来。

一、策略模式（Strategy Pattern）

通俗定义：要执行一些方法，方法有几个，什么方法，这些是固定的；但是方法的实现是不一样的，有多种策略，那这个时候，就可以定义一个基本的封装方法的接口，然后再定义不同的策略实现类。这样在调用的时候，只需要传入指定的区分不同策略的条件，然后调用具体的方法就可以了。

举个简单例子，支付场景，都有下单，支付，支付成功后的回调等基本方法，但是支付的策略可以是支付宝支付，微信支付，或者银联支付。这个时候就可以采用策略模式。

这个策略模式，在使用到获取具体策略时，又同步使用到了工厂模式和单例模式，来初始化具体的一个策略。

 结合我们的应用场景，比如生成租金明细，是一个基本方法，但是有多种策略，根据不同的策略来进行区分，使用特定的策略。

那这里缺点也是比较明显了：就是再调用策略方法前，你是一定要能够区分出到底使用哪个具体的策略的。

二、委派模式（Delegate Pattern）

委派模式 和代理模式，策略模式很像

这里的理解主要是：

委派模式 注重结果，

代理模式 注重过程

策略模式 注重可扩展性（外部扩展性）

可以理解 ：委派模式 = 静态代理 + 策略模式

举个例子：

领导，经理，职员A，职员B，职员C

1.领导命令经理做事

2.经理根据领导命令委派员工做事

2.1如果是“登录”，委派A 做事（登录）

2.2如果是“校验”，委派B 做事（校验）

2.3如果是“完善”，委派C 做事（完善）

整个流程就是领导需要命令一个事情，经理相当于是中间人，根据不同的命令，去委派不同的职员来做事。

三、代理模式（Proxy Pattern）

A 要做一件事method，但是没法直接去做，B能直接做method，这个时候，A可以通过B来做method。相当于是B是A 找的代理。

这里有分为2种情况：

1.静态代理

就是A要去做method这个事情的时候，是知道由B来做的，就是需要B去代理实现的时候，A是很清楚的。就是上面的 委派模式，经理委派具体某个职员去做事。

再比如java代码链接多数据源数据，业务层只执行的时候，去连接数据库，根据分表分库的原则，来判断去链接具体的数据库表。

2.动态代理

就是A要去做method这个事情的时候，不知道由谁来做，这个由谁来做，是动态的，是在要做的时候根据一些参数在执行时候才明确的。所以称为动态代理。

代理模式主要是有2个目的：

1.保护代理对象

职员能做method事情，但是对上级使用是经理暴露出去，如果领导需要有其他的安排，都是对经理而言，职员还是只需要做method事情即可。

2.增强代理对象

第1点已经有这个意思，就是在职员能做事method基础上能让领导再安排职员做事时，能做更多的事情。