【设计模式】行为型模式

       行为型模式一共有10个，分别是观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代器模式。

观察者模式 

       定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。 

 优点：

1、可以实现表示层和数据逻辑层的分离。

2、在观察目标和观察者之间建立一个抽象的耦合。

3、增加新的具体观察者时，不需要修改原有系统代码。

缺点：

1、如果一个观察目标对象有很多直接和间接观察者，将所有观察者都通知，会花费很多时间。

2、如果观察者和观察目标之间存在循环依赖，会导致循环调用，从而导致系统崩溃 。

模板方法模式

       定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。        

 优点：

1、在父类中定义一个算法，由它的子类来实现细节的处理。

2、模板方法是一种代码复用技术，可以将公共行为放在父类中。

3、可以通过子类来覆盖父类的基本方法。

缺点： 需要为每一个基本方法的不同实现提供一个子类，如果父类中可变的基本方法太多，会导致系统更加庞大，降低系统性能。

命令模式 

       将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作。

优点：

1、降低耦合度。因为请求者和接收者之间不存在引用，请求者和接收者之间是完全解耦的。

2、增加灵活性。由于增加新的具体命令类不会影响其他类，所以增加新的类时很容易。

3、可以比较容易的设计一个命令队列。

4、为请求的撤销和恢复操作提供了一种设计和实现方案。

缺点：可能会导致某些系统有过多的具体命令类。因为针对每一个请求接收者的调用操作都需要设计一个具体命令类。

状态模式 

       允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。

 优点：

1、封装了状态的转换规则，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中。 

2、将所有与某个状态有关的行为放到一个类中 。

3、可以让多个环境对象共享一个状态对象 。

缺点：

1、状态模式使用，会导致系统运行开销增大 。

2、状态模式如果使用不当，会增加系统设计难度。

职责链模式 

       使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

 优点：

1、对象不需要知道是哪儿一个对象处理他的请求，只需要知道这个请求会被处理，从而降低了系统的耦合度。

2、增加灵活性，可以通过在运行时对该链进行动态的增加或修改来增加或改变处理一个请求的职责。

3、在系统中增加一个新的具体请求处理者时，不需要修改原有系统的代码，只需要在客户端重新建链即可。

缺点：

1、由于一个请求没有明确的接受者，这个请求不一定会被处理。

2、对于比较长的职责链，可能涉及到多个处理对象，系统性能受到影响。

3、如果职责链建立的不是太合理，可能会造成循环调用，使系统陷入死循环。

解释器模式

       给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

 优点：

1、 可扩展性比较好，灵活。

2、 增加了新的解释表达式的方式。

3、 易于实现文法。

缺点： 

1、 执行效率比较低，可利用场景比较少。

2、 对于复杂的文法比较难维护。

 中介者模式

       用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

 优点：

1、简化了对象之间的关系，将系统的各个对象之间的相互关系进行封装，将各个同事类解耦，使得系统变为松耦合。

2、提供系统的灵活性，使得各个同事对象独立而易于复用。

 缺点：

1、中介者模式中，中介者角色承担了较多的责任，所以一旦这个中介者对象出现了问题，整个系统将会受到重大的影响。

2、新增加一个同事类时，不得不去修改抽象中介者类和具体中介者类，此时可以使用观察者模式和状态模式来解决这个问题。

 访问者模式

        表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的操作。

优点： 

1、增加新的操作很容易。

2、将有关元素对象的访问行为集中到一个访问者对象中，而不会分散在一个个的元素类中。 

缺点： 

1、使增加新的数据结构变得困难了。 

2、破坏封装。

策略模式 

       它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

 优点：

1、策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。

2、简化了单元测试，因为每个算法都自己的类，可以通过自己的接口单独测试。

缺点： 

1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择

恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

2，策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。

3，无法同时在客户端使用多个策略类，也就是说，在使用策略模式时，客户端每次只能使用一个策略类，不支持使用一个策略

类完成部分功能后再使用另一个策略类来完成剩余功能的情况。

备忘录模式

       在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

 优点：

1、有时一些发起人对象的内部信息必须保存在发起人对象以外的地方，但是必须要由发起人对象自己读取，这时，使用备忘录模式可以把复杂的发起人内部信息对其他的对象屏蔽起来，从而可以恰当地保持封装的边界。

2、本模式简化了发起人类。发起人不再需要管理和保存其内部状态的一个个版本，客户端可以自行管理他们所需要的这些状态的版本。

3、当发起人角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。

 缺点：

1、如果发起人角色的状态需要完整地存储到备忘录对象中，那么在资源消耗上面备忘录对象会很昂贵。

2、当负责人角色将一个备忘录 存储起来的时候，负责人可能并不知道这个状态会占用多大的存储空间，从而无法提醒用户一个操作是否很昂贵。

3、当发起人角色的状态改变的时候，有可能这个协议无效。如果状态改变的成功率不高的话，不如采取“假如”协议模式。

迭代器模式 

       提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。

 优点：

1、迭代器模式使得访问一个聚合对象的内容而无需暴露它的内部表示，即迭代抽象。

2、迭代器模式为遍历不同的集合结构提供了一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。

缺点：迭代器模式在遍历的同时更改迭代器所在的集合结构会导致出现异常。所以使用foreach语句只能在对集合进行遍历，不能在遍历的同时更改集合中的元素。