GOF论述了23种设计模式，它们有3个分类————创建型模式、结构型模式、行为模式。
此篇为行为模式
行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。
行为模式所关注的重点是：算法与对象之间的职责是如何分配的。
行为模式通常都对类或者对象相互之间的通信形式进行描述。通常，行为模式是依赖于继承机制在类之间分派行为的。
通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象 之间的交互。在系统运行时，对象并不是孤立的，它们可以通过相互通信与协作完成某些复杂功能，一个对象在运行时也将影响到其他对象的运行。
大部分行为模式的主题是对变化进行封装。
当一个应用某个方面的特征会有比较频繁的改变时，行为模式就会使用一个对象来封装这个方面。
***************************************************************************
模板方法模式
定义：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。
模板方法模式定义了一个算法的步骤，并允许子类别为一个或多个步骤提供其实践方式。让子类别在不改变算法架构的情况下，重新定义算法中的某些步骤。
模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。
适用场景：
|-----一次性地实现一个算法不变的部分，而将可变的行为留给子类来实现。
|-----当子类中有公共的行为可以提取到公共的父类当中，并且子类有自己的“个性化要求”时。
|-----一般，子类可以扩展的地方都是固定的，即允许在这些点进行扩展。这也是模板方法模式的局限性。
说明：
事实上，模板方法模式就是一种的调用结构，即从抽象父类调用子类的方法，而不是传统意义上的子类调用父类的方法。
正是这种奇特的结构，使扩展和维护更加方便。
***************************************************************************
策略模式：定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化不会影响到使用算法的客户。
|-----利用策略模式，开发人员将可相互替代的方案封装在某些类的内部，类之间是相互分离的，每个类都将实现一个与策略有关的公共操作。
|-----这个公共操作会定义策略的输入及输出，但是具体的操作实现则是由各个类分别来实现。
|-----策略模式封装了变化。
说明：
一个策略就是一个计划，通过执行这个计划，可以在既定的输入下给出特定的输出。
一般情况下，为了获得这个输出，使用策略比使用算法要有更广阔的选择空间。
策略可以表达为一组方案，这些方案之间可以进行互相替换（也可以理解为一组算法）。
适用场景：
|-----很多相关的类只是在行为上有差异。
|-----当需要使用一个算法的不同变体时。
|-----使用算法的客户不应该知道算法的具体结构时。
|-----当一个类定义了许多种行为并且这些行为在这个类的操作中以多个条件语句的形式出现时。
***************************************************************************
观察者模式
|-----定义了一种一对多的依赖关系，让多个观察对象同时监听某一个主题对象。
|-----这个主题对象在状态发生改变时，会通知所有观察者对象，使他们能够自动更新自己。
缺点：
|-----当需要增加通知者，就需要修改客户端以及观察者的代码来达到要求，这不符合“开放-封闭”原则。
|-----所以需要对通知者进行抽象。
当一个系统被分割成一系列相互协作的类时会有一个副作用，就是必须维护与之相关的对象之间的一致性。
开发人员并不希望为了保持这种一致性而导致各个类之间的紧密耦合，因为这样会给维护和扩展以及重用带来极大的不便。
而观察者模式就是解决这一问题的一个良好的方案！
|-----一个被观察者可以有任意数目的依赖于它的观察者，当被观察者的状态发生改变时，所有的观察者都会收到通知。
|-----而被观察者在发出通知时也无需知道谁在观察自己
|-----同时，每一个观察者也并不知道其他的观察者的存在
总之，使用观察者模式的最终结果就是解除耦合。让互相耦合的双方都依赖于抽象而不是具体。这样一来，任何一方的改变都不会影响另一方。
观察者模式的适用场景：
|-----当一个抽象模型有两个方面，其中一个方面必须依赖于另一个方面时；
|-----当一个对象的改变需要同时改变其他的对象但是却不知道具体有多少个对象等待改变时；
|-----当一个对象必须通知其他对象但是却不能与其他对象造成紧密耦合时
***************************************************************************
中介者模式————用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显示地相互引用，从而使耦合松散，而且可以独立地改变他们之间的交互。
|-----当开发人员发现系统出现“多对多”的复杂交互对象群体时，不要急着使用中介者模式，而是先反思自己的系统在设计上是不是不合理。
缺点：如果系统庞大且复杂，中介对象也可能会庞大、复杂————职责过多。
中介者模式的适用场景：
|-----当一组对象以定义良好但是复杂的方式进行通信时，所产生的相互依赖关系结构混乱并且难以理解，这时就需要中介者模式出马。
|-----当一个对象要引用很多其他对象并且直接与这些对象进行通信，导致难以复用该对象时。
|-----开发人员想要定制一个分布在多个类中的行为但是却不想生成太多的子类时。
***************************************************************************
迭代器模式————提供一种方法，顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示
|-----提供一种顺序访问某个集合中所有元素的解决方案，而不用了解集合底层的操作。
|-----现在新兴的语言都将迭代器集成了进去。
|-----迭代器提供的不仅仅是从头到尾的遍历方式，还有从后往前的遍历方式。
|-----迭代器是“单一职责”原则的完美体现。
Java中的Iterable接口：
|-----该接口实现后的功能是“返回”一个迭代器，常用的实现了该接口的子接口有Collection<E>等。
|-----接口的iterator()方法返回一个标准的Iterator实现，实现这个接口允许对象成为for-each语句的目标，进行底层遍历。
迭代器的本质：
将遍历聚合对象中的数据的行为提取出来，并把其封装到一个迭代器中，通过专门的迭代器去遍历聚合对象的内部数据。