【笔记】《HeadFirst设计模式》(2) —— 从模板方法模式到其他

本篇包括8-14章的内容，其中14章的内容我拆成了很多个小点，正好两篇完结这本书的笔记。因为书的后半部分信息量要密集很多，尽管字数不多，这篇内容还是比较难的，耐心看吧。在本篇的最后我把书结尾的连线题写为了容易阅读的表格作为最终的总结。

想到面试(如果有的话)应该也快了，接下来会复习一下算法导论，可能会写一两篇也可能不会，内容也不会是全书而是节选，暂且我埋个坑在这儿。

8 模板方法模式

• 模板方法模式就是常说的框架，是一系列算法的集合，各处都可以遇到，例如JAVAapi的排序算法
• 让基类定义好一系列抽象代码的执行，final一些不可改变的算法，abstract一些需要子类自己实现的算法，默认实现一些可选算法，空实现hook算法。然后让基类以一个不可改变的步骤算法来调用准备好的步骤
• 好莱坞原则：让子类去调整具体实现但基类来决定何时调用，避免高层与低层有明显的环状依赖，降低高低类的耦合

9 迭代器模式&组合模式

• 迭代器是让我们游走于数据结构内而又无需暴露其内部的结构和遍历的方法
• Java中的很多标准数据结构都有官方的迭代器(Iterator)，通过实现迭代器接口能让我们自己的类也支持迭代器

• 组合模式是将相关的类以树状组合起来，结点和叶子实现一样的接口这样迭代器可以一视同仁，但是结点和叶子又是不一样的类这样插入删除可以判断效果，结点通常用一个同样接口的链表来保存孩子
• 组合模式的遍历用BFS或DFS，自己显式用栈来运算比较高效
• 迭代器的遍历不是很方便，可以给迭代器加上父指针方便插入删除，也可以加入一个暂存迭代器来优化迭代器的断点续查
• 类似空指令，空迭代器也是很好的设计思路
• 单一责任原则:类应该想好自己的责任，负责管理数据的类最好就不要参与遍历的工作

10 状态模式

• 状态模式由状态机(Context)类和状态(State)类组成，与传统的依赖条件判断的状态机不同的是方法实现委托了状态类来处理，分离了控制与运行
• 状态机负责管理通用数据并对外提供方法的入口，但是其本身只完成最小部分的工作，方法的实现委托给状态类处理
• 状态类负责具体的实现，当对动态状态切换要求大的时候负责一些状态的转换，当状态的改变是静态时转换可以放在状态机类处理

11 代理模式

• 代理(proxy)是一个中间对象，它代表着真实的对象，提供与真实对象一致的接口，但是方法的内容审核并转交请求到真实对象上，代理自身负责实现一些无关的低层细节，如网络细节
• 代理类似于装饰者模式，但是区别是代理隐藏了一些原始接口，对暴露在外的接口进行访问控制，对复杂的操作进行封装整合，优化对对象的操作工作，很少多次包装。而装饰者模式为对象增加了行为而且常常多次包装对象
• 有各种各样的代理模式可以运用：

12 复合模式&MVC模式

• 复合模式有机地将之前的模式结合起来，其中结合得最好最实用的是MVC(模型-视图-控制器)模式，相互解耦了显示，调用，运算

• 用户与视图交互，视图通知控制器
• 控制器与模型交互，控制器也可能会要求视图做出改变(按钮是否按下)
• 视图回想模型询问状态，模型发生改变时也会通知视图；有些设计中模型的改变也会通知控制器
• 不要把控制器和视图混在一起，因为这样视图就有了两个责任，造成了紧耦合，难以扩展和改变

• 模型常常使用观察者模式，控制器用策略模式，视图用组合模式
• 适配器模式可把新的模型适应到旧的控制器和视图上，或者反之

13 在真实世界中实践模式

• 设计模式是某情景Context(不断出现的拥有一定重复共性的需要应用模式解决的情况)下，针对某问题(情景下的约束和目标)采取的某种解决方案(所追求的一个解决问题的通用方案)
• 学习设计模式时应该先记住名称，然后看其意图理解定义，接着看动机和适用性看是否符合需求。接着看其结果，了解模式的优缺点。确定好目标模式后，看结构来了解类图，查看参与者得知各个组件的意义，最后看相关的实现和范例。下图是四人组的模式介绍模板：

• 模式不是被创建的，而是被发现的，要了解现有的模式，反思自己的设计经验，总结出来模式写成文档，依据别人的反馈修改，满足三次规则后才能说自己设计了一个模式
• 模式的分类如下：

• 设计模式有以下几个要点：
  • 保持简单：不是如何用模式，而是当模式能让设计变简单时用
  • 模式并非万灵丹：要考虑模式对其他部分的影响
  • 何时用模式：当前解决方案不满足问题或考虑到未来会改变时
  • 用模式的机会：重构代码时是最好的机会
  • 删除模式：当系统变得异常复杂，一个简单的解决方案能让系统变简单时删除模式
  • 不需要就不做：只有当有确切的实际的理由去使用模式时才用，否则只会让系统变复杂

14.1 桥接模式

• 你不止可以改变你的实现，也可改变你的抽象，即抽象和实现都包含了一部分具体实现
• 上图中的RemoteControl和TV就是桥接，它们的方法被下面的实现类调用，然后它们互相是抽象类又相关引用，它们的方法以对所引用的抽象来实现
• 下面的实现类不破坏抽象类的方法，而是调用抽象类的方法所以实现的改变不会影响抽象，抽象的改变会同步改变实现，只要抽象的接口不改变就能保持抽象和实现的松耦合
• 缺点是需要在一开始就设计好抽象和实现的关系，这点非常困难

14.2 生成器模式

• 类似工厂模式，只是我们可以通过参数接入工厂的生产得到不同的实例
• 允许对象通过多个步骤创建，比工厂更自由
• 缺点是需要更多知识来控制参数

14.3 责任链模式

• 最常见的真实世界使用就是异常处理，以类似递归的方式把目标传出来，每个handler都进行一次尝试处理，若无法处理则继续返回
• 优点是让每个对象都无需了解整个链的结构
• 特点是不能保证一定会被处理
• 缺点是不容易观察运行时的特征

14.4 蝇量模式

• 当存在许多许多几乎相同的实例时可用此模式
• 也就是复制一个一样的实例然后调用其部分参数
• 缺点是实例无法拥有自己独特的方法

14.5 解释器模式

• 主要用于形式语言的解释
• 每个语法规则表示为一个类，然后调用语法中每个成分的interpret来解释整个句子
• 缺点当语法数目过多时此模式会变得非常巨大繁杂

14.6 中介者模式

• 原本复杂的类间调用转为各个类与同一个中间交流，由中介转接其中的请求
• 优点是让类与类解耦，增加复用性
• 缺点是如果设计不当，复杂性会积累在中介处

14.7 备忘录模式

• 只储存关键对象的关键状态，然后可用这些状态还原所需的对象
• 让状态与对象本身分离有助于维护内聚
• 缺点是储存备忘与恢复也可能非常耗时

14.8 原型模式

• 预先准备好一些设计好的原型对象，然后按照情况返回所需的对象，类似于工厂模式
• 优点是隐藏了创造对象的复杂性，客户可以产生客户还不知道的对象
• 缺点是复制对象本身可能也很复杂

14.9 访问者模式

• 所有目标类都设置一个getState方法，此方法返回类的每个有意义的参数
• 访问者通过调用getState来得到信息
• 客户通过访问者得到所需的有筛选的信息
• 优点是访问代码的集中和让实际类可以自由操作只要正确返回getState即可
• 缺点是打破了封装性，类外本来有很多信息不应该了解到

0* 设计模式总结