行为型模式
模版方法模式 常用又简单
场景。相同的在子类重复写。
解决办法。 最简单的模式，就是把共性的放到父类，不同的放到子类。
命令模式、
场景。调用对象时，需要做一起其他操作，例如日志，准备参数，事务上的撤销等，为了避免每个调用的位置都重复。
解决办法。把这些调用操作和调用前的准备，以及附加操作，封装到一起，统一管理。
迭代器模式、
场景。集合的遍历式访问，大致一样，可整合成上一个下一个等。
解决办法。所有访问用迭代器
观察者模式、
场景。有的程序需要有一种通知机制，当一个对象变化时，其他对象得到通知，如果设计的不好，就会使这种通知过于紧密耦合。
解决办法。用观察者模式来通知其他一个或多个对象，并更新被通知对象。
中介者模式、
场景。当系统中各模块之间通信时，有时一个模块需要与很多模块通信，如果这样的模块多，会导致通信很复杂。
解决办法。做一个类似主板的类，这个类当中介，总成各个模块间的通信。
备忘录模式、常用
场景。有时需要恢复对象到一个之前的状态，如发生了什么情况，需要恢复。
解决办法。在对象之外，保存对象的各个状态的属性。
解释器模式、
场景。一个复杂公式的计算，可能更复杂到有很多参数，客户程序不用用。
解决办法。进行解释这个公式。
状态模式、
场景。if else(或switch case)语句的增多或者修改）可能会引起很大的修改，而程序的可读性，扩展性也会变得很弱。维护也会很麻烦。
解决办法。用状态模式，看起来是在不同条件下，改变了类，其实是改变了状态
策略模式、类似状态模式
场景。算法增加时，用子类扩展时，if else(或switch case)变得很复杂。同样情况是业务规则。
解决办法。以相同方式调用所有算法，减少算法类与调用算法类之间的耦合。同时可简化的按每个算法测试。这样就封装了业务规则，这里专门处理业务规则。
职责链模式、
场景。客户程序发出的请求，多个处理程序可处理，但无法确定是哪个程序处理，但一定在这些处理程序里，当这些处理程序发生变化时，客户程序也需要改，这些都增加了客户程序和处理程序之间的耦合度。
解决办法。把客户程序的请求，放到把这些处理程序绑到一起的链子上，不用管谁处理，只需把请求放到链子上即可，链子上的环节变化也不用改客户程序的发出请求方式。
访问者模式。
场景。结构已固定，要加需求，不想改原结构，改原结构用装饰模式小改。
解决办法。类似加入一个访问者，给现结构扩展方法。