设计模式| 行为型模式 (上)

生活中，对一个问题解决，有多种方案可以选择。比如出行旅游去某地，要选择交通工具的问题上。

- 如果没有时间但是不在乎钱，可以选择坐飞机。
- 如果没有钱，可以选择坐大巴或者火车。
- 如果再穷一点，可以选择骑自行车。

组织架构好这些灵活多样的算法（选择），而且可以随意互相替换。这种解决方案就是策略模式。

 在策略模式结构图中包含如下几个角色：
  ● Context（环境类）：环境类是使用算法的角色，它在解决某个问题（即实现某个方法）时可以采用多种策略。
    在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。

  ● Strategy（抽象策略类）：它为所支持的算法声明了抽象方法，是所有策略类的父类，它可以是抽象类或具体类，也可以是接口。
    环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。

  ● ConcreteStrategy（具体策略类）：它实现了在抽象策略类中声明的算法，在运行时，
    具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。

策略模式的主要优点有：

策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。

易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。

避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，
在上一篇文章中我们已经提到，使用多重条件判断是非常不容易维护的。

 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。

必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，
因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。
例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，
是不是先要明白这三种算法的适用情况？再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，
客户端是不是也要明白链表和数组有什么区别？就这一点来说是有悖于迪米特法则的。

做面向对象设计的，对策略模式一定很熟悉，因为它实质上就是面向对象中的继承和多态，在看完策略模式的通用代码后，
我想，即使之前从来没有听说过策略模式，在开发过程中也一定使用过它吧？至少在在以下两种情况下，大家可以考虑使用策略模式，

  A.几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
  B.有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
   
策略模式是一种简单常用的模式，我们在进行开发的时候，会经常有意无意地使用它，一般来说，
策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。

在现实生活中，很多事情都包含几个实现步骤，例如请客吃饭，无论吃什么，一般都包含点单、吃东西、买单等几个步骤，
通常情况下这几个步骤的次序是：点单 --> 吃东西 --> 买单。在这三个步骤中，点单和买单大同小异，
最大的区别在于第二步——吃什么？吃面条和吃满汉全席可大不相同，

在软件开发中，有时也会遇到类似的情况，某个方法的实现需要多个步骤（类似“请客”），其中有些步骤是固定的（类似“点单”和“买单”）
而有些步骤并不固定，存在可变性（类似“吃东西”）。为了提高代码的复用性和系统的灵活性，
可以使用一种称之为模板方法模式的设计模式来对这类情况进行设计，
在模板方法模式中，将实现功能的每一个步骤所对应的方法称为基本方法（例如“点单”、“吃东西”和“买单”），
而调用这些基本方法同时定义基本方法的执行次序的方法称为模板方法（例如“请客”）。

在一个子类中提供“吃面条”的实现，而另一个子类提供“吃满汉全席”的实现。
通过使用模板方法模式，一方面提高了代码的复用性，另一方面还可以利用面向对象的多态性，在运行时选择一种具体子类，
实现完整的“请客”方法，提高系统的灵活性和可扩展性。

  大部分刚步入职场的毕业生应该都有类似这样的经历。一个复杂的任务，
  由公司中的牛人们将主要的逻辑写好，然后把那些看上去比较简单的方法写成抽象的，交给其他的同事去开发。
  这种分工方式在编程人员水平层次比较明显的公司中经常用到。
  比如一个项目组，有架构师，高级工程师，初级工程师，则一般由架构师使用大量的接口、抽象类将整个系统的逻辑串起来，
  实现的编码则根据难度的不同分别交给高级工程师和初级工程师来完成。这就是典型的用到了模版方法模式。

 模版方法模式由一个抽象类和一个（或一组）实现类通过继承结构组成，抽象类中的方法分为三种：

 1. 抽象方法：父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
 2.  模版方法：由抽象类声明并加以实现。一般来说，模版方法调用抽象方法来完成主要的逻辑功能，
            并且模版方法大多会定义为final类型，指明主要的逻辑功能在子类中不能被重写。
 3. 钩子方法：由抽象类声明并加以实现。但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。

 抽象类的任务是搭建逻辑的框架，通常由经验丰富的人员编写，因为抽象类的好坏直接决定了程序是否稳定性。
 实现类用来实现细节。抽象类中的模版方法正是通过实现类扩展的方法来完成业务逻辑。只要实现类中的扩展方法通过了单元测试，
 在模版方法正确的前提下，整体功能一般不会出现大的错误。

 容易扩展。一般来说，抽象类中的模版方法是不易反生改变的部分，而抽象方法是容易反生变化的部分，
 因此通过增加实现类一般可以很容易实现功能的扩展，符合开闭原则。

 便于维护。对于模版方法模式来说，正是由于他们的主要逻辑相同，才使用了模版方法，假如不使用模版方法，
 任由这些相同的代码散乱的分布在不同的类中，维护起来是非常不方便的。

 比较灵活。因为有钩子方法，因此，子类的实现也可以影响父类中主逻辑的运行。
 但是，在灵活的同时，由于子类影响到了父类，违反了里氏替换原则，也会给程序带来风险。这就对抽象类的设计有了更高的要求。

 在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。
 在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。

观察者模式是使用频率最高的设计模式之一，它用于建立一种对象与对象之间的依赖关系，
一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。
在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者， 
一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。

   观察者模式定义如下：

观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，
其相关依赖对象皆得到通知并被自动更新。
观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、
源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。

在最基础的观察者模式中，包括以下四个角色：

被观察者：从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，
        是因为多线程操作时，Vector在是安全的，而List则是不安全的），
        这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；
        detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，
        也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。

具体的被观察者：使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
观察者：观察者角色一般是一个接口，它只有一个update方法，在被观察者状态发生变化时，这个方法就会被触发调用。
具体的观察者：观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。

 观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。

 观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，
 由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。
 并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。

迭代器模式定义如下：

 迭代器模式是一种使用频率非常高的设计模式，
 通过引入迭代器可以将数据的遍历功能从聚合对象中分离出来，聚合对象只负责存储数据，而遍历数据由迭代器来完成。
 由于很多编程语言的类库都已经实现了迭代器模式，因此在实际开发中，
 我们只需要直接使用Java、C#、OC等语言已定义好的迭代器即可，迭代器已经成为我们操作聚合对象的基本工具之一。

1、字典中的（有两个方法）：
  - (NSEnumerator<KeyType> *)keyEnumerator;//获取所有key值
  - (NSEnumerator<ObjectType> *)objectEnumerator;//获取所有value值

2、数组中的（有两个方法）
  - (NSEnumerator<ObjectType> *)objectEnumerator;//正向遍历数组    ——>完全可用 for in 语法代替
  - (NSEnumerator<ObjectType> *)reverseObjectEnumerator;//反向遍历数组

解释器模式介绍

也就是说，如果你想自己开发一种语言来解释执行某些语言的特定语法，可以考虑使用解释器模式。

该模式对于我们开发人员来说，基本上都用不到。除非你想自己开发一种语言。

解释器模式真正开发起来很难，就相当于自己开发了一种语言给别人用。

解释器模式UML图：

通常来说，当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树叶，则可以使用解释器模式。

EL表达式的处理

正则表达式解释器

SQL语法的解释器

数学表达式解释器：Math 、   Expression String Parser 、 Expression4J

很多情况下，在一个软件系统中可以处理某个请求的对象不止一个，
例如SCM系统中的采购单审批，主任、副董事长、董事长和董事会都可以处理采购单，他们可以构成一条处理采购单的链式结构，
采购单沿着这条链进行传递，这条链就称为职责链。职责链可以是一条直线、一个环或者一个树形结构，最常见的职责链是直线型，
即沿着一条单向的链来传递请求。链上的每一个对象都是请求处理者，
职责链模式可以将请求的处理者组织成一条链，并让请求沿着链传递，
由链上的处理者对请求进行相应的处理，客户端无须关心请求的处理细节以及请求的传递，
只需将请求发送到链上即可，实现请求发送者和请求处理者解耦。

 职责链模式定义如下：

  ● Handler（抽象处理者）：它定义了一个处理请求的接口，一般设计为抽象类，
                        由于不同的具体处理者处理请求的方式不同，因此在其中定义了抽象请求处理方法。
                        因为每一个处理者的下家还是一个处理者，因此在抽象处理者中定义了一个抽象处理者类型的对象
                       （如结构图中的successor），作为其对下家的引用。通过该引用，处理者可以连成一条链。

  ● ConcreteHandler（具体处理者）：它是抽象处理者的子类，可以处理用户请求，在具体处理者类中实现了抽象
                               处理者中定义的抽象请求处理方法，在处理请求之前需要进行判断，看是否有相应的处理权限，
                               如果可以处理请求就处理它，否则将请求转发给后继者；
                               在具体处理者中可以访问链中下一个对象，以便请求的转发。

 责任链模式与if…else…相比，他的耦合性要低一些，因为它把条件判定都分散到了各个处理类中，
 并且这些处理类的优先处理顺序可以随意设定。责任链模式也有缺点，这与if…else…语句的缺点是一样的，
 那就是在找到正确的处理类之前，所有的判定条件都要被执行一遍，当责任链比较长时，性能问题比较严重。

就像开始的例子那样，假如使用if…else…语句来组织一个责任链时感到力不从心，代码看上去很糟糕时，
就可以使用责任链模式来进行重构。

 责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中，这样做的优点是比较灵活了，
 但同样也带来了风险，比如设置处理类前后关系时，一定要特别仔细，搞对处理类前后逻辑的条件判断关系，
 并且注意不要在链中出现循环引用的问题。