09装饰与外观模式

12.09装饰与外观模式2023-04-24

定义：动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。
1. 对象结构型模式
2. 以对客户透明的方式动态地给一个对象附加上更多的责任
3. 在不需要创建更多子类的情况下，让对象的功能得以扩展
简单结构：4个角色
1. Component（抽象构件）
2. ConcreteComponent（具体构件）
3. Decorator（抽象装饰类）
4. ConcreteDecorator（具体装饰类）
UML

定义：要求客户端完全针对抽象编程，装饰模式的透明性要求客户端程序不应该将对象声明为具体构件类型或具体装饰类型，而应该全部声明为抽象构件类型
1. 对于客户端而言，具体构件对象和具体装饰对象没有任何区别
2. 可以让客户端透明地使用装饰之前的对象和装饰之后的对象，无须关心它们的区别
3. 可以对一个已装饰过的对象进行多次装饰，得到更为复杂、功能更为强大的对象
4. 无法在客户端单独调用新增方法addedBehavior()

定义：半透明(Semi-transparent)装饰模式：用具体装饰类型来定义装饰之后的对象，而具体构件使用抽象构件类型来定义
1. 对于客户端而言，具体构件类型无须关心，是透明的；但是具体装饰类型必须指定，这是不透明的
2. 可以给系统带来更多的灵活性，设计相对简单，使用起来也非常方便
3. 客户端使用具体装饰类型来定义装饰后的对象，因此可以单独调用addedBehavior()方法
4. 最大的缺点在于不能实现对同一个对象的多次装饰，而且客户端需要有区别地对待装饰之前的对象和装饰之后的对象
装饰模式的优缺点
1. 优点：
  - 装饰模式比继承更加灵活，不会导致类的个数急剧增加
  - 通过配置文件可以在运行时选择不同的具体装饰类，从而实现不同的行为
  - 可以对一个对象进行多次装饰
  - 具体构件类与具体装饰类可以独立变化，符合开闭原则
2. 缺点：
  - 使用装饰模式进行系统设计时将产生很多小对象
  - 比继承更加易于出错，排错也更困难
装饰模式的适用环境
1. 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责
2. 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装饰模式

定义：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
- 对象结构型模式
- 又称为门面模式，是迪米特法则的一种具体实现
- 所指的子系统是一个广义的概念
简单结构：2个角色
1. Facade（外观角色）
2. SubSystem（子系统角色）
UML：
优缺点：
1. 优点：
  - 它对客户端屏蔽了子系统组件
  - 它实现了子系统与客户端之间的松耦合关系
  - 一个子系统的修改对其他子系统没有任何影响，而且子系统的内部变化也不会影响到外观对象
2. 缺点：
  - 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性
  - 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则
适用环境：
1. 要为访问一系列复杂的子系统提供一个简单入口
2. 客户端程序与多个子系统之间存在很大的依赖性
3. 在层次化结构中，可以使用外观模式的定义系统中每一层的入口，层与层之间不直接产生联系，降低层之间的耦合度