目前设计模式的介绍已经很多，自己也有一定的了解，但是在代码落地中不够，与业务的结合还比较欠缺。
那通过这篇文章记录下：在思考特定的设计模式的时候，如何恰如其分的与我们的业务结合起来，并进行落地。
我觉得要思考到这一点，或这个层面的话，也是需要对业务有很深的理解，然后对具体的某个设计模式有深刻的认识，才能将他们结合起来。
策略模式（Strategy Pattern）
通俗定义：要执行一些方法，方法有几个，什么方法，这些是固定的；但是方法的实现是不一样的，有多种策略，那这个时候，就可以定义一个基本的封装方法的接口，然后再定义不同的策略实现类。这样在调用的时候，只需要传入指定的区分不同策略的条件，然后调用具体的方法就可以了。
举个简单例子，支付场景，都有下单，支付，支付成功后的回调等基本方法，但是支付的策略可以是支付宝支付，微信支付，或者银联支付。这个时候就可以采用策略模式。
这个策略模式，在使用到获取具体策略时，又同步使用到了工厂模式和单例模式，来初始化具体的一个策略。
结合我们的应用场景，比如生成租金明细，是一个基本方法，但是有多种策略，根据不同的策略来进行区分，使用特定的策略。
那这里缺点也是比较明显了：就是再调用策略方法前，你是一定要能够区分出到底使用哪个具体的策略的。
委派模式（Delegate Pattern）
委派模式 和代理模式，策略模式很像
这里的理解主要是：
委派模式 注重结果，
代理模式 注重过程
策略模式 注重可扩展性（外部扩展性）
可以理解 ：委派模式 = 静态代理 + 策略模式
举个例子：
领导，经理，职员A，职员B，职员C
领导命令经理做事
经理根据领导命令委派员工做事
如果是“登录”，委派A 做事（登录）
如果是“校验”，委派B 做事（校验）
如果是“完善”，委派C 做事（完善）
整个流程就是领导需要命令一个事情，经理相当于是中间人，根据不同的命令，去委派不同的职员来做事。
代理模式（Proxy Pattern）
A 要做一件事method，但是没法直接去做，B能直接做method，这个时候，A可以通过B来做method。相当于是B是A 找的代理。
这里有分为2种情况：
静态代理
就是A要去做method这个事情的时候，是知道由B来做的，就是需要B去代理实现的时候，A是很清楚的。就是上面的 委派模式，经理委派具体某个职员去做事。
再比如java代码链接多数据源数据，业务层只执行的时候，去连接数据库，根据分表分库的原则，来判断去链接具体的数据库表。
动态代理
就是A要去做method这个事情的时候，不知道由谁来做，这个由谁来做，是动态的，是在要做的时候根据一些参数在执行时候才明确的。所以称为动态代理。
代理模式主要是有2个目的：
1.保护代理对象 职员能做method事情，但是对上级使用是经理暴露出去，如果领导需要有其他的安排，都是对经理而言，职员还是只需要做method事情即可。 2.增强代理对象 第1点已经有这个意思，就是在职员能做事method基础上能让领导再安排职员做事时，能做更多的事情。
