程序设计模式23+1种定义+UML图（有部分分析和联用）

程序设计模式这门课已经学完了，复习的时候做了一个这样的汇总，希望可以给后来学习这门课的同学一些帮助。

• • 设计模式的分类
    • 根据目的（模式是用来做什么的）可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三类：
      •  创建型模式主要用于创建对象
      •  结构型模式主要用于处理类或对象的组合
      •  行为型模式主要用于描述类或对象如何交互和怎样分配职责

• • 面向对象设计原则：
    • 单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
    • 开闭原则：软件实体应当对扩展开放，对修改关闭。
    • 里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。
      • 在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。
      • 在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型
    • 依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
    • 接口隔离原则：客户端不应该依赖那些它不需要的接口
    • 合成复用原则：优先使用对象组合，而不是继承来达到复用的目的。
    • 迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

• • 创建型模式
  • 简单工厂模式 (Simple Factory Pattern)：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。
    • 
    • 不符合开闭原则
    • 简单工厂模式的简化：将抽象产品类和工厂类合并，将静态工厂方法移至抽象产品类中

• • 

• • 工厂方法模式：定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。
    • 
    • 符合开闭原则

• • 抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。
  • 
    • 新增产品族支持开闭原则
    • 新增产品结构违背开闭原则

• • 建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
    • 

• • 原型模式：使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。
  • 
    • 浅克隆和深克隆
    • 违背开闭原则

• • 单例模式：确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。
    • 要点：
      • 某个类只能有一个实例
      • 必须自行创建这个实例
      • 必须自行向整个系统提供这个实例
      • 
      • 饿汉式单例类：
        • 属性就是单例，直接getinstance就可以
      • 懒汉式单例类
        • 锁方法延迟，双重锁定，两次判断instance==null

结构型模式

• • 结构型模式(Structural Pattern)关注如何将现有类或对象组织在一起形成更加强大的结构
  • 不同的结构型模式从不同的角度组合类或对象，它们在尽可能满足各种面向对象设计原则的同时为类或对象的组合提供一系列巧妙的解决方案
  • 
  • 适配器模式：将一个类的接口转换成客户希望的另一个接口。适配器模式让那些接口不兼容的类可以一起工作。
    • 
  • 桥接模式：将抽象部分与它的实现部分解耦，使得两者都能够独立变化。
    • 

• • 

• • 组合模式：组合多个对象形成树形结构以表示具有部分-整体关系的层次结构。组合模式让客户端可以统一对待单个对象和组合对象。
    • 

• • 
  • 透明组合模式：抽象构建就声明函数
    • 好处，客户端一视同仁
    • 问题，不安全
  • 安全组合模式：抽象构件就一个operation，剩下的要在composite里自己声明
    • 问题，不透明，区别对待叶子和容器

• • 装饰模式：动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。
    • 

• • 外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
    • 

• • 

facade那里直接init子系统，做个函数都用上就可以了

• • 享元模式：通过共享技术实现相同或相似对象的重用
    • 享元池(Flyweight Pool)：存储共享实例对象的地方
    • 享元模式：运用共享技术有效地支持大量细粒度对象的复用。
    • 

• • 代理模式：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。
    • 
    • 常见的有多种代理模式：
      • 远程，虚拟，缓冲，保护，智能引用

• • 当客户端对象需要访问远程主机中的对象时可以使用远程代理
  • 当需要用一个消耗资源较少的对象来代表一个消耗资源较多的对象，从而降低系统开销、缩短运行时间时可以使用虚拟代理
  • 当需要为某一个被频繁访问的操作结果提供一个临时存储空间，以供多个客户端共享访问这些结果时可以使用缓冲代理
  • 当需要控制对一个对象的访问，为不同用户提供不同级别的访问权限时可以使用保护代理
  • 当需要为一个对象的访问（引用）提供一些额外的操作时可以使用智能引用代理

• • 行为型模式：
    • 行为型模式(Behavioral Pattern) 关注系统中对象之间的交互，研究系统在运行时对象之间的相互通信与协作，进一步明确对象的职责
    • 行为型模式：不仅仅关注类和对象本身，还重点关注它们之间的相互作用和职责划分

• • 职责链模式：避免将一个请求的发送者与接收者耦合在一起，让多个对象都有机会处理请求。将接收请求的对象连接成一条链，并且沿着这条链传递请求，直到有一个对象能够处理它为止。
    • 
    • 记得抽象类要可以设置下家的函数（successor）

• • 命令模式：将一个请求封装为一个对象，从而让你可以用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。
    • 
      • 有一个小套娃，invoker有command，可以调用execute，实现receiver的action

• • 解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
    • 
    • 非终结部分需要两个抽象表达符号，递归进行interpret

• • 迭代器模式：提供一种方法顺序访问一个聚合对象中各个元素，且不用暴露该对象的内部表示。
    • 
    • 符合开闭原则，如果不动迭代器方法的话
    • 用在访问聚合对象的内部环境里

• • 中介者模式：定义一个对象来封装一系列对象的交互。中介者模式使各对象之间不需要显式地相互引用，从而使其耦合松散，而且让你可以独立地改变它们之间的交互。
    • 是迪米特法则的典型应用
    • 

• • 

• • 备忘录模式：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样就可以在以后将对象恢复到原先保存的状态。
    • 

• • 观察者模式：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象都得到通知并被自动更新。
    • 
    • 目标类中应该含有观察者列表
    • 增加新的具体目标类，在一定程度上违背了开闭原则
    • 但是整体是符合开闭原则的。增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标之间不存在关联关系的情况下，增加新的观察目标也很方便

• • 状态模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
    • 
    • request：调用对应状态的handle
    • 对于开闭原则的支持性不太好

• • 策略模式：定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法可以独立于使用它的客户变化。
    • 
    • 使用环境：
      • 一个系统需要动态地在几种算法中选择一种
      • 避免使用难以维护的多重条件选择语句
      • 不希望客户端知道复杂的、与算法相关的数据结构，提高算法的保密性与安全性

• • 模板方法模式：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。
    • 

• • 如果需要更换或增加具体子类，无须修改源代码，只需修改配置文件即可，符合开闭原则
  • 也符合单一职责原则
  • 可以配合桥接模式

• • 访问者模式：表示一个作用于某对象结构中的各个元素的操作。访问者模式让你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
    • 
    • 开闭原则的倾斜性
    • 访问者模式可以和组合模式联用
      • 

• • 一个对象结构包含多个类型的对象，希望对这些对象实施一些依赖其具体类型的操作
  • 需要对一个对象结构中的对象进行很多不同的且不相关的操作，并需要避免让这些操作“污染”这些对象的类，也不希望在增加新操作时修改这些类
  • 对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作