再回首——行为型设计模式

 行为型

    设计模式被分成三大类，创建型，结构型，行为型。具体要阐述为什么这么分，这个问题，暂时解决不了，但是我们能做的是，合理的运用它。对于行为型设计模式，区别于其他两种的就是：它侧重的是对“方法”的操作。

下面是对几个行为型的设计模式的理解。

一、模板方法

    1、概述

      将一个操作的算法的骨架和具体算法实现分离——解耦
    ​  ​骨架在父类中，算法延迟到子类实现，就可以有N多实现——多态的体现

      回顾一下类图，看看模板解决的问题：
     

    ​模板的眼:；解决代码重复，会算法有既定顺序。

• 使用继承，解决代码重复的问题，重复的代码抽象成一个基类，做成模板；杜绝子类出现不变的代码，模板就是为了给子类瘦身。

• 基类中有代码实现:这里抽象出来不单单是某几个方法声明，方法中是可以有代码实现的。只要是会发生重复的就放到父类中。

• 算法顺序：父类中（模板）必须有一个既定的方法来执行算法顺序——算法的骨架，是既定的

• 子类只是不同算法的实现父类，不改变算法结构

    ​2、改造模板----算法骨架灵活

       算法的骨架是既定的，可以修改吗？要不要修改？

      这里的算法骨架顺序跟建造模式类似，顺序基本是稳定。怎么说呢？

一般使用这两种模式的“事物”，它的构成顺序都是稳定的，不是经常需要变动的，这是一个前提，但是并不是说，这个顺序一定不可以改变，为了灵活编程，可以通过委托来实现。往委托队列注册的过程就是排序的过程，委托是一大块，不多说了。

    ​   子类可以扩展父类吗？

      当然是可以扩展的，因为是继承呀。但是个人认为没有多大意义。如果只是为了添加方法到子类中，跟复写方法无关联，那就是有点破坏单一原则的味道了。
   
    3、建造模式VS模板模式

    ​相同:都有既定的顺序，仅此而已。

    ​不同:两个设计模式的适用范围不同，解决问题不同，一个是创建型，一个是行为型，其他就不用啰嗦了吧。

二、观察者

    ​1、观察者的几点认识

•  一对多的依赖关系

• 多个对象观察一个主题

• 主题发生变化，观察的对象随之变化

    ​主题与观察对象，观察对象之间都是陌生的。一方负责变化，通知；一方负责接收，做出对应变化。

    ​生活中的实例:订阅网站。

    通过类图来分析观察者的优缺点：
   

    ​优点:解耦是观察者的一大特色。通过依赖倒转，面向接口编程的思想，给多个观察者增加父类接口，让被通知者成为主动观察者，来实现观察者和主题的衔接。

    ​不足:主题只能和一种类型的观察者进行关联——从途中可以看出所有的观察者都是继承自一个父类：observer，所以这些观察者都是一个父类，要想增加多个类型的观察者，便有心无力了。

    ​2、观察模式进阶委托

      那要是我想通知多个类型的观察者怎么办？答案还是——委托​

1. 想要通知其他类型的观察者，需要如下改动:最大的局限就是这个抽象的接口——observer，那么就把它去掉。

2. 抽象类不存在，那么主题中通知的方法（notify）就没有意义了，也去掉。

3. 将动态通知观察者的权利从主题移交给调用者。——主题和观察者彻底解耦。

4. 声明委托，在调用短端注册各种类型的观察者，执行调用。

   
   

三、策略模式:封装算法，算法变化不影响用户使用。
    ​​（具体的在上篇博客中已经写到了）

总结：行为型的设计模式还有：职责链，命令，解释，迭代，中介者，备忘录，状态，访问者模式。这里只写了三个，其他的几个没有这几个上手。对于剩下的几个模式：我们本着一个这样的原则：what？when？how？