文档介绍：观察者模式
适用性
在以下任一情况下可以使用观察者模式：
1. 当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使他们可以各自独立地改变和复用
，而不知道具体组合模式
意图
=>将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式 使客户能够一致地处理单个对象和对象组合。即所谓的递归组合。
动机
组合模式
动机
适用性
以下情况使用组合模式:
=>你想表示对象的部分-整体层次结构；
=> 你想要用户能够忽略对象组合与单个对象的差异，用户将一致地处理组合结构中的所有对象。
组合模式
效果
=>收益
→使得更容易增加新类型的组件
→使得客户代码更简单，因为客户不必知道他们正在 处理的是叶组件还是组合组件。
=>缺陷
→使得更难以限制组合中的组件类型
外观模式
意图
=>为子系统中的一组接口提供一个一致的界面，外观模式定义了一个使子系统更易于使用的高层接口。
动机
=>将一个系统划分为若干个子系统有利于降低系统的复杂性
=> 子系统是一组类，或一组类和其他子系统
=> 被一个子系统(或一组子系统)中的类暴露的接口能够变得相当复杂
=> 降低这种复杂性的途径之一是就是引入一个外观对象，它为子系统中较一般的设施提供一个单一而简单的接口。
外观模式
适用性
以下情况使用外观模式：
=>为一个复杂子系统提供一个简单接口时。该接口对大多数客户而言都足够好；更高级的客户能够穿越外观对象。
=>将子系统的类与客户和其他子系统分离，从而提高子系统的独立性和可移植性
外观模式
效果
=>收益
→ 它对客户隐藏子系统的实现，从而使子系统更易于使用
→ 它有利于子系统与客户之间的弱耦合。这就允许改变所包含的子系统但不影响客户。
→ 在大型软件系统中降低编译依赖性
→ 简化将系统移植到其他平台的过程，因为编译一个子系统一般不需要编译所有其他的子系统。
→ 不阻止高级客户访问低层类
→ 注意：外观不增加任何功能，它只是简化接口
=>缺陷
→ 不阻止高级客户访问低层类！
状态模式
意图
=>允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
动机
状态模式(续)
适用性
以下情况可使用状态模式
=>对象的行为取决于其状态, 并且它必须在运行期根据该状态改变它的行为。
=>一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。状态模式将每一个条件分支放入一个独立的类中
状态模式
效果
=>收益
→将所有与一个状态相关的行为都放入一个对象中
→允许状态转换逻辑结合到状态对象中而不是放入单块的if或switch 语句。
→有助于避免不一致的状态，因为状态改变的发生只使用一个状态对象，不是几个对象或属性
=>缺陷
→增加了对象的数量
策略模式
意图
=> 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
动机
策略模式
适用性
以下情况使用策略模式：
→很多相关的类仅仅是其行为有异
→需要使用一个算法的不同变体
→算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
→一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。可将相关的条件分支移入它们各自的Strategy 类中以代替这些条件语句。
策略模式
效果
=>收益
→ 提供Context的备选子类以得到各种算法或行为
→ 消除庞大的条件语句
→ 提供相同行为的实现选择
=>缺陷
→ 增加对象数目
→ 所有算法必须使用相同的Strategy接口
策略模式
注意状态模式与策略模式之间的相似！其差异是意图之一。
=>状态对象封装依赖状态的行为（和可能的状态转换）
=>策略对象封装算法
他们均为具有委托的组合的实例！
命令模式
意图
=>将一个对象的服务请求封装到其他对象内，从而使你可用不同的方式操纵这些请求。
动机
命令模式
动机
适用性
以下情况使用命令模式
=>想要实现回调函数功能
=>想要在不同的时刻指定、排列和执行请求
=>需要支持取消和改变日志操作
命令模式
效果
=>命令模式将调用操作的对象与知道如何实现该操作的对象解耦
=>Command是头等的对象。它们可像任何其他对象一样被操纵和扩展
=>多个命令能被装配成一个复合命令
代理模式
意图
=>为其他对象提供一种代理以控制对这个对象的访问。
别名
=>代理
动机
=>代理是
→被授权代表另一个人的人
→代理或