17.2 装饰模式的定义
17.2 装饰模式的定义
装饰模式(Decorator Pattern)是一种比较常见的模式,其定义如下:
Attach additional responsibilities to an object dynamically keeping the same interface.Decorators provide a flexible alternative to subclassing for extending functionality.(动态地给一个对象添加一些额外的职责。 就增加功能来说,装饰模式相比生成子类更为灵活。)
装饰模式的通用类图如图17-5所示。
- Component抽象构件
Component是一个接口或者是抽象类,就是定义我们最核心的对象,也就是最原始的对象,如上面的成绩单。
注意 在装饰模式中,必然有一个最基本、最核心、最原始的接口或抽象类充当 Component抽象构件。
- ConcreteComponent 具体构件
ConcreteComponent是最核心、最原始、最基本的接口或抽象类的实现,你要装饰的就是它。
- Decorator装饰角色
一般是一个抽象类,做什么用呢?实现接口或者抽象方法,它里面可不一定有抽象的方法呀,在它的属性里必然有一个private变量指向Component抽象构件。
- 具体装饰角色
ConcreteDecoratorA和ConcreteDecoratorB是两个具体的装饰类,你要把你最核心的、最原始的、最基本的东西装饰成其他东西,上面的例子就是把一个比较平庸的成绩单装饰成家长认可的成绩单。
装饰模式的所有角色都已经解释完毕,我们来看看如何实现,先看抽象构件,如代码清单17-10所示。
代码清单17-10 抽象构件
1 | public abstract class Component { |
具体构件如代码清单17-11所示。
代码清单17-11 具体构件
1 | public class ConcreteComponent extends Component { |
装饰角色通常是一个抽象类,如代码清单17-12所示。
代码清单17-12 抽象装饰者
1 | public abstract class Decorator extends Component { |
当然了,若只有一个装饰类,则可以没有抽象装饰角色,直接实现具体的装饰角色即可。具体的装饰类如代码清单17-13所示。
代码清单17-13 具体的装饰类
1 | public class ConcreteDecorator1 extends Decorator { |
注意 原始方法和装饰方法的执行顺序在具体的装饰类是固定的,可以通过方法重载实现多种执行顺序。
我们通过Client类来模拟高层模块的耦合关系,看看装饰模式是如何运行的,如代码清单17-14所示。
代码清单17-14 场景类
1 | public class Client { |