Command－－对象行为型模式
意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
别名
Action，Transaction
适用性
- 抽象出待执行的动作以参数化某对象
- 在不同的时刻指定、排列和执行请求。
- 支持取消操作。
- 支持修改日志。
- 用构建在原语操作上的高层操作构造一个系统。
结构
效果
- Command模式将调用操作的对象和知道如何实现该操作的对象解藕。
- Command是头等的对象。它们可以像其他的对象一样被操纵和扩展。
- 你可将多个命令装配成一个符合命令
- 增加新的Command很容易，因为这无需改变已有的类。
实现问题
- 一个命令对象应达到何种只能程度
- 支持取消（undo）和重做（redo）
- 避免取消操作过程中的错误积累
- 使用C++模板
Template method----类行为模式
意图
定义一个操作的算法的骨架，而将一个步骤延迟到子类中。
适用性
- 一次性实现一个算法的部分，并将可变的行为留给子类来实现。
- 各子类中的公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。
- 控制子类扩展。
结构
效果
模板方法导致一种反向控制，这种结构有时被称为“好莱坞法则”，即“别找我们，我们找你”。
实现
有三个问题值得注意：
- 使用C++访问控制，一个模板方法调用的原语操作可以被定义为保护成员。
- 尽量减少原语操作
- 命名约定
这种模式我们基本每天都在用，android开发中Activity的onCreate,onResume， View中的draw等等。
Strategy－－对象行为型模式
意图
定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。本模式使得算法可以独立于使用它的客户而变化。
别名
Policy
适用性
- 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法
- 需要使用一个算法的不同变体。
- 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
- 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形势出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句
结构
协作
- Strategy和Context相互作用以实现选定的算法。当算法被调用时，Context可以将算法所需要的所有数据都传递给该Strategy。或者，Context可以将自身作为一个参数传递给Strategy操作。这就让Strategy在需要时可以回调Context。
- Context将它的客户的请求转发给它的Strategy。客户通常创建并传递一个ConcreteStrategy对象给该Context；这样，客户仅与Context交互。通常有一系列的ConcreteStrategy类可供客户选择。
效果（优缺点）
- 相关算法系列
- 一个替代继承的方法
- 消除一些条件语句
- 实现的选择
- 客户必须了解不同的Strategy
- Strategy和Context之间的通信开销
- 增加了对象数目
实现问题
- 定义Strategy和Context接口
- 将Strategy作为模板参数
- 使Strategy对象成为可选的
