今天是设计模式连载的第三篇，记录了责任链模式，装饰模式，策略模式。同样每个设计模式的详解都包括的我的理解以及我的分析推导过程。

责任链模式

理解：

• 该设计模式可以用来封装上层模块对底层逻辑的感知，将底层的执行逻辑封装成链式结构，上层模块不再需要知道具体的一个业务场景应该由哪一个底层模块来处理。
• 类似模板方法模式，抽象类中定义好公共的链条节点的执行逻辑（抽象方法）和传递逻辑，而具体的底层实现类则只需实现执行逻辑（抽象方法）即可。

分析／推导：

• 如果不用该设计模式，上层调用者则需要知道各个业务场景应该调用对应的哪一个底层模块。
• 使用该设计模式，则可以做到具体的调用模块对上层透明，通用的调用和传递逻辑在抽象方法里定义即可。
• 缺点，调用链路可能会比较复杂，不适合问题的追踪定位。

装饰模式

理解：

• 为了解决业务扩展时无限增加子类的问题，使用装饰类，类似代理类的特性，来扩展原有的方法。
• 装饰模式相对于继承增加子类的方式，可以做到动态装饰，只需要动态增加外层的包装类即可（想想ByteInputStream, BufferedInputStream 等）。

分析／推导：

• 该设计模式是当需要在底层模块上进行扩展，考虑到如果简单继承的话方法覆盖重写的话，底层模块会很臃肿，不易维护。
• 对底层模块增加一层代理，即装饰接口，同样继承底层模块接口，装饰类则仅需完成一些扩展的工作，核心仍然是调用底层模块，并且返回类型仍然是底层模块接口类型。
• 装饰类返回的类型仍然是底层模块类型，装饰类所做的工作对上层来说透明，上层仍然是按照底层模块接口类型的使用方式来使用装饰类。
• 装饰类可以动态嵌套，一般是需要你在new的时候将 代理／修饰 的核心对象传递过来即可，配合上上一条，即传递的核心对象即可以是底层模块，也可以是已经被装饰类封装之后的代理类。

策略模式

理解：增加策略模块（strategy），并用上下文（context）来封装策略的具体调用。

分析／推导：

• 典型的策略模式只是定义了一个策略模块，上层将具体的某一个策略传递给context，然后context来负责策略的实际调用。
• 按照典型的方式思考，我觉得策略模式用处不大，首先面向接口编程这是很正常的，策略也就是接口的实现。而上层照样需要感知具体的某一个策略调用，context只是接收上层确定的一个策略然后具体执行而已，所以context的意义也不大，上层完全可以在确定某一个策略之后然后再执行即可。
• 我的改进
  • 我认为上层可以封装一下他的request信息，包含元数据和需要，context来动态确定需要用哪一个或者哪几个策略来具体完成上层的这个需求。
  • 这么的改动很像命令模式，上层封装的request就是一个command，而context就是receiver，这个command具体应该由哪一个执行者或者哪几个执行者来执行完全由context来决定。
  • 这样的改动减少了底层对上层的侵入，上层无需感知具体有哪些策略，只要封装需求即可。符合迪米特法则，仅依赖朋友类型，并且依赖越少越好。
  • 底层策略的改动无需再对上层负责，仅需保证context的调用没问题即可。