行为型模式（一）

观察者模式（老板回来？我不知道！）：定义对象间的一种一对多的依赖关系，让对个观察者对象同时监听某一个主题对象。当这个主题对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

符合开闭原则和依赖倒转原则， 让程序都依赖抽象，而不是相互依赖，也不是依赖具体的实现。

为什么要使用观察者模式：将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维护一致性而使各类紧密耦合，这样会给维护、扩展和复用都带来不便，用上观察者模式就好办多了
何时用：当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。当一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。解除耦合。

模板方法模式（考题抄错会做也白搭）：定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。老师出一份试卷，就是一个结构不变的算法，让学生填写他们各自的答案，就是重定义该算法的某些特定步骤，在填写答案处可以设置一个虚方法，给继承的子类重写，这样就让子类重复的代码上升到了父类，而不是让每个子类都去重复。把不变行为搬移到超类，去除子类的重复代码来体现它的优势。

当我们要完成在某个细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法模式来处理。好处：提高代码的复用，灵活

命令模式（烤羊肉串引来的思考）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作。将行为请求者与行为实现者解耦，对请求排队或记录请求日志，以及支持可撤销的操作

就烤羊肉串来说，把烤肉串者类当中的方法，分别写成多个命令类，泛化出一个抽象类，被服务员请求，让服务员只管对抽象的命令发号施令就可以了。

优点：它能较容易地设计一个命令队列；在需要的情况下，可以较容易地将命令记入日志；允许接收请求的一方决定是否要否决请求。可以容易地实现对请求的撤销和重做，由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

状态模式（无尽加班何时休）：允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化，消除庞大的条件分支语句。不同的状态有不同的行为，多个不同状态，继承抽象状态，避免了类过于复杂的逻辑判断，做到代码的责任分解。

好处：将与特定状态相关的行为局部化，并且将不同状态的行为分割开来；将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于对应的那个状态中，所以通过定义新的子类可以很容易地增加新的状态和转换。把各种状态转移逻辑分布到抽象状态类的子类之间，来减少相互间的依赖。

职责链模式（加薪非要老总批？）：使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

这样发出这个请求的客户端并不知道这当中的哪一个对象最终处理这个请求，这样系统的更改可以在不影响客户端的情况下动态地重新组织和分配责任。定义一个处理请求的接口，具体处理者类实现接口，具体处理者类沿着这条链将请求传递下去，直到请求被处理。职责链简化了对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。大大降低了耦合度。随时随地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。