结构型设计模式

适配器模式

• 目标
  将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• 参与者
  • 使用者,其实一般都是一个方法
  • 被使用者,可以是类或者接口,但是是类的话,对于
  • 试图作为被使用者的类
  • 一个新建的适配器类(需要把不兼容的类作为构造函数参数传起来)
• 结构
• 场景
  • 本质上在调用处多了一个转换的步骤
  • 想复用原来的逻辑,但是不想改变/新增原来的代码结构(没有权限改,原来的代码很稳定等等)
  • 典型的调用方想方法来解决,且不想变更任何东西
  • 实际上使得原来的接口功能增强(兼容更多种数据)

桥接模式

• 目标
  • 最大程度复用共有逻辑
  • 把所有不同的地方都用接口或者抽象类来替代
• 参与者
  • 一套套的子组件/逻辑
  • 一个继承体系
• 结构
  • 类图
    
• 场景
  • 一个复杂逻辑被非常多的客户端调用,但是又有多个不同点,可以在共同点放在继承体系,不同点抽象出来
  • 典型的被调用方进行重构
  • 希望在运行时配置/生成逻辑
  • 可以和抽象工厂模式配合生成一套套完整逻辑
  • 也可以利用构造者模式,把创建过程独立出来,如果是希望通过配置来生成逻辑可以用这个

组合模式

• 目标
  • 使得组合对象和单一对象有着统一的操作方式/行为
• 参与者
  • 一个接口
  • 一堆单一对象,都要实现上面的接口
  • 一堆组合对象,都要实现上面的接口
• 结构
• 场景
  • 没想出有什么应用场景,可能是树结构的时候可以构造出来,然后简化操作吧
  • 组织树结构有很大的用处
  • 可能纯粹是为了把单一对象的行为递归去操作

装饰模式

• 目标
  • 本质上为原来的行为增加若干个步骤
  • 增强功能
  • 可能增强多个功能,也可以理解为增加了按顺序执行的多个步骤
• 参与者
  • 一个功能类
  • 一个增强功能接口
  • 一堆装饰类
• 结构
• 场景
  • 动态增加功能(操作步骤),不使用继承
  • 不改动原来的代码
  • 典型的被调用方变化

外观模式

• 目标
  为子系统中的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
• 参与者
• 结构
• 场景
  • 没啥好讲的,就是提供一个类/接口给外部调用

享元模式

• 目标
  • 运用共享技术有效地支持大量细粒度的对象。
  • 有两类:
    • 严格满足条件的场景,即有内部状态作为共享和工厂作为共享的场景,才称为享元模式
    • 只有一个工厂去共享也可称为享元模式
• 参与者
  • Flyweight类(对于一个类,里面不变的东西(内部状态)抽出来作为flyweight)
  • ConcreteFlyweight(拥有内部状态Flyweight(作为成员变量),和外部状态)
  • FlyweightFactory类,将concreteFlyweight实例化并缓存起来
• 结构
  • 类图
    
• 场景
  • 线程安全的对象且大对象

代理模式

• 目标
  • 给目标对象/类增加功能,改变功能
• 参与者
• 结构
• 场景