将所有的观察者都通知到会花费很多时间/如果存在循环调用可能导致系统崩溃/没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的,而仅仅知道观察目标发生了变化
适用场景
一个抽象模型有两个方面,其中一个方面依赖于另一个方面,将这两个方面封装在独立的对象中使它们可以各自独立地改变和复用
模板方法概念
定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使的子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
优点
首先从设计上将变与不变区分开，将不变的部分抽取出来定义在父类中/能够实现算法骨架的统一，通过切换不同的子类类实现不同的功能，很符合开闭原则，里氏替换原则
缺点
类数目的增加，每一个抽象类都需要一个子类来实现，这样导致类的个数增加
类数量的增加，间接地增加了系统实现的复杂度。
适用场景
需要固定的算法骨架，实现一个公共部分，将可变的部分交给子类去实现；
命令模式概念
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，可以对请求进行排队或记录请求日志，以及支持可撤销的操作
优点
降低对象之间的耦合度/调用同一方法实现不同的功能
缺点
如果子类太多，就会导致Command非常庞大
适用场景
当需要先将一个函数登记上，然后再以后调用此函数时，就需要使用命令模(其实就是回调函数)
状态模式概念
允许一个对象在其内部活动状态改变它的行为，让对象看起来似乎修改了它的类
优点
封装了转换规
允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块
可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数
缺点
状态模式的使用必然会增加系统类和对象的个数/状态模式对“开闭原则”的支持并不太好，如果需要进行切换某个状态，需要去源码中进行修改
适用场景
对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为/代码中包含大量与对象状态有关的条件语句
职责链模式概念
使多个对象都有机会处理请求，从而避免请求的发送者和接受者之前的耦合关系，将这些对象形成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
优点
将请求和处理分开，实现解耦，提高系统的灵活性/简化了对象，使对象不需要知道链的结构
缺点
当职责链过长，性能会受到影响
调试不方便。采用了类似递归的方式，调试时逻辑可能比较复杂
不能保证请求一定被接收
使用场景
多个对象可以处理同一个请求
可动态指定一组对象处理请求
解释器模式概念
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言的句子
优点
可扩展性高
缺点
解释器模式会引起类膨胀
使用了大量的循环和递归，效率是一个不容忽视的问题
适用场景
可以将一个需要解释执行的语言中的句子表示为一个抽象语法树
一个简单语法需要解释的场景
中介者模式概念
用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立的改它们之间的交互
优点
解耦。把同事类原来一对多的依赖变成一对一的依赖，降低同事类的耦合度，同时也符合了迪米特原则。
缺点
中介者模式把业务流程和协调都写在中介者，当同事类越多，中介者的业务就越复杂，造成不好管理的弊端
如果要增减同事类，必须得修改抽象中介者角色和具体中介者角色类。
适用场景