本博客大部分内容来于免费在线学习设计模式
1:装饰模式
装饰模式是一种结构型设计模式,允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。即在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)。
2:装饰模式问题
假设你正在开发一个提供通知功能的库,其他程序可使用它向用户发送关于重要事件的通知。
库的最初版本基于通知器(Notifier)类,其中只有很少的几个成员变量,一个构造函数和一个send发送方法。该方法可以接收来自客户端的消息参数,并将该消息发送给一系列的邮箱,邮箱列表则是通过构造函数传递给通知器的。作为客户端的第三方程序仅会创建和配置通知器对象一次,然后在有重要事件发生时对其进行调用。
在不断发展后,有些用户希望使用微信通知,使用QQ通知,又或者使用短信通知。最简单的方法是: 扩展通知器类,然后在新的子类中加入额外的通知方法。现在客户端要对所需通知形式的对应类进行初始化,然后使用该类发送后续所有的通知消息。
但如果用户希望组合不同的方式,如果创建特殊子类来整合的话,代码量会迅速膨胀。而且不仅是程序库,客户端也是如此。
3:装饰模式解决方案
使用扩展当前类来增加功能有以下两个问题:
- 继承是静态的。你无法在运行时更改已有对象的行为,只能使用由不同子类创建的对象来替代当前的整个对象。
- 子类只能有一个父类。大部分编程语言不允许一个类同时继承多个类的行为。
另一种方法是使用聚合或组合,而不是继承。两者的工作方式几乎一模一样: 一个对象包含指向另一个对象的引用,并将部分工作委派给引用对象; 继承中的对象则继承了父类的行为,它们自己能够完成这些工作。
聚合组合是许多设计模式背后的关键原则 (包括装饰在内)。
- 聚合:对象A包含对象B;对象B可以独立存在而不依赖A。
- 组合:对象A由对象B组成;A负责管理B的生命周期。B无法独立于A存在。
封装器是装饰模式的别称,这个称谓明确地表达了该模式的主要思想。 “封装器” 是一个能与其他 “目标” 对象连接的对象。封装器包含与目标对象相同的一系列方法,它会将所有接收到的请求委派给目标对象。但是,封装器可以在将请求委派给目标前后对其进行处理,所以可能会改变最终结果。
例如将邮件通知放在基类中,将其他所有通知方法放在装饰中。
客户端代码必须将基础通知器放入一系列自己所需的装饰中。因此最后的对象将形成一个栈结构。
例如衣服是装饰,人是基类。你可以通过组合衣服获得不同效果。觉得冷时,你可以穿一件毛衣。如果穿毛衣还觉得冷 你可以再套上一件夹克。如果遇到下雨,你还可以再穿一件雨衣。所有这些衣物都 “扩展” 了你的基本行为,但它们并不是你的一部分,如果你不再需要某件衣物,可以方便地随时脱掉。
4:装饰模式结构
- 部件 (Component) 声明封装器和被封装对象的公用接口。
- 具体部件 (Concrete Component) 类是被封装对象所属的类。它定义了基础行为,但装饰类可以改变这些行为。
- 基础装饰 (Base Decorator) 类拥有一个指向被封装对象的引用成员变量。该变量的类型应当被声明为通用部件接口,这样它就可以引用具体的部件和装饰。装饰基类会将所有操作委派给被封装的对象。
- 具体装饰类 (Concrete Decorators) 定义了可动态添加到部件的额外行为。具体装饰类会重写装饰基类的方法,并在调用父类方法之前或之后进行额外的行为。
- 客户端 (Client) 可以使用多层装饰来封装部件,只要它能使用通用接口与所有对象互动即可。
代码示例:
基本功能:文件的下载和读取。在此基础上,可以选择对文件进行加密或者压缩。又或者添加两个功能。
1 | // 客户端(Client) |
运行结果如下:
1 | ---添加加密和解密功能--- |
可以看出,在基础功能上可以自由组合功能。
5:装饰模式适用场景
- 在无需修改代码的情况下使用对象,且希望在运行时为对象新增额外的行为
- 装饰能将业务逻辑组织为层次结构,你可为各层创建一个装饰,在运行时将各种不同逻辑组合成对象。由于这些对象都遵循通用接口,客户端代码能以相同的方式使用这些对象。
- 用继承来扩展对象行为的方案难以实现或者根本不可行
- 许多编程语言使用 final最终关键字来限制对某个类的进一步扩展。复用最终类已有行为的唯一方法是使用装饰模式: 用封装器对其进行封装。
6:装饰模式优缺点
优点 | 缺点 |
---|---|
你无需创建新子类即可扩展对象的行为。 | 在封装器栈中删除特定封装器比较困难。 |
你可以在运行时添加或删除对象的功能。 | 实现行为不受装饰栈顺序影响的装饰比较困难。 |
你可以用多个装饰封装对象来组合几种行为。 | 各层的初始化配置代码看上去可能会很糟糕。 |
单一职责原则。你可以将实现了许多不同行为的一个大类拆分为多个较小的类。 |
装饰和代理有着相似的结构,但是其意图却非常不同。这两个模式的构建都基于组合原则,也就是说一个对象应该将部分工作委托给另一个对象。两者之间的不同之处在于代理通常自行管理其服务对象的生命周期和功能的扩展,而装饰的生成则总是由客户端进行控制。
7:装饰模式与其他模式关系
- 适配器模式可以对已有对象的接口进行修改,装饰模式则能在不改变对象接口的前提下强化对象功能。此外,装饰还支持递归组合,适配器则无法实现。
- 适配器能为被封装对象提供不同的接口,代理模式能为对象提供相同的接口,装饰则能为对象提供加强的接口。
- 责任链模式和装饰模式的类结构非常相似。两者都依赖递归组合将需要执行的操作传递给一系列对象。但是,两者有几点重要的不同之处。
责任链的管理者可以相互独立地执行一切操作,还可以随时停止传递请求。另一方面,各种装饰可以在遵循基本接口的情况下扩展对象的行为。此外,装饰无法中断请求的传递。 - 组合模式和装饰的结构图很相似,因为两者都依赖递归组合来组织无限数量的对象。
装饰类似于组合,但其只有一个子组件。此外还有一个明显不同:装饰为被封装对象添加了额外的职责,组合仅对其子节点的结果进行了 “求和”。
但是,模式也可以相互合作:你可以使用装饰来扩展组合树中特定对象的行为。 - 大量使用组合和装饰的设计通常可从对于原型模式的使用中获益。你可以通过该模式来复制复杂结构,而非从零开始重新构造。
- 装饰可让你更改对象的外表,策略模式则让你能够改变其本质。
- 装饰和代理有着相似的结构,但是其意图却非常不同。这两个模式的构建都基于组合原则,也就是说一个对象应该将部分工作委派给另一个对象。两者之间的不同之处在于代理通常自行管理其服务对象的生命周期,而装饰的生成则总是由客户端进行控制。