代码精进之路-设计模式-UML图(行为型)

十三、责任链模式

请求与处理中解耦，不需要关注处理者是谁，把请求扔到这个处理链上即可

比较常用的设计模式，对后继者的管理可以通过一个简单的链表实现，也可以通过数组实现，tomcat中实现的过滤器链是通过数组来管理链上的节点的

十四、命令模式

Command模式是回调机制的一个面向对象的代替品

十五、解释器模式

十六、迭代器模式

提供一种顺序访问集合中元素的方法，而又不需要了解集合内部的数据结构

十七、中介者模式

网状交互变星状交互，它和门面模式的区别是双向都可以发起请求

十八、备忘录模式

又叫快照模式，其实就是关于状态的备份、存储与恢复问题

十九、观察者模式

观察者模式的关键在于 提供一种观察者的注册机制，再来一个事件广播器。

用于 1对多 的事件订阅与发布。

二十、状态模式

现实中很多例子，当状态发生变化时，行为就会随之切换，传统的解法中会包含大量swich分支，各个状态之间的行为耦合严重，而用状态设计模式可以巧妙的解耦，使代码向开闭原则靠近，

状态上下文中要维持一个  当前状态 指针，当状态发生变化时 这个指针就会指向下一个正确的状态对象，谁去执行这个 切换动作呢？每个状态的实现者非常了解这些状态之间的迁移关系，当自己的状态被执行后，它会将上下文中的那个指针指向下一个正确的状态对象

二十一、策略模式

这可能是最简单的设计模式之一了，策略上下文根据参数切换策略实现对象，策略实现者之间完全隔离，这是和状态模式的区别，它的切换靠上下文

二十二、模板方法模式

这个是为数不多的用了继承来实现的设计模式

二十三、访问者模式

对AST抽象语法树的访问中大量用到这个设计模式，被访问者 需要提供 固定的 accept方法，Visitor中也提供固定的visitor方法，通过参数不同来大量重载visitor方法，被访问者一般会将this作为参数传递到visitor方法中进行回调，这就巧妙了。

总结

如果没有丰富的项目编码经验的支撑是很难理解设计模式的或者说理解是肤浅的，最好的方式是先把理论记住，再研究开源框架是如何使用的，再在自己的项目中寻找合适的场景进行实践，这个过程要反复进行（理论联系实际），理解才会越来越深，有些设计模式是和场景密切关联的，个别的在实际工作中有可能一辈子也用不到，毕竟你的工作范围是有限的，我们要把常用的设计模式熟练掌握住就差不多了，冷门的遇到了再研究也不迟。