装饰模式
动机和定义
一般有两种方式可以实现给一个类或对象增加行为。
- 继承机制。使用继承机制是给现有类添加功能的一种有效途径,通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但这种方法是静态的,用户不能控制增加行为的方式和时机。
- 关联机制。即将一个类的对象嵌入另一个对象中,由另一个对象来决定是否调用嵌入对象的行为,以便扩展自己的行为,我们称这个嵌入的对象为装饰器 ( Decorator )。
装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任,换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不需要创造更多子类地情况下,将对象的功能加以扩展。这就是装饰模式的模式动机。
装饰模式 ( Decorator Pattern ):动态地给一个对象增加一些额外的职责,就增加对象功能来说,装饰模式比生成子类实现更加灵活。其别名也可称为包装器 ( Wrapper ),与适配器模式的别名相同,但是他们适用于不同的场合。根据翻译不同,装饰模式也有人称为“油漆工模式”,它是一种对象结构型模式。
结构与角色
- Component:抽象组件,规范准备接收附加责任的对象,具体组件和装饰的公共父类型。
- Concrete Component:具体组件,定义一个将要接收附加责任的类,可以通过给它添加装饰来增加新的功能。、
- Decorator:装饰者,是所有装饰的公共父类,它定义了所有装饰必须实现的方法,同时它还保存了一个对于Component的引用,以便将用户的请求转发给Component,并可能在转发请求前后执行一一些附加的动作。
- Concrete Decorator:具体装饰者,负责给组件对象增加具体的附加责任。
示例代码
// 抽象组件接口
interface Component{
// 功能方法
void operation();
}
// 具体组件类
class ConcreteComponent implements Component{
public ConcreteComponent(){
}
// 功能方法
public void operation(){
System.out.println("hello in ConcreteComponent");
}
}
// 装饰类,实现了Component接口
class Decorator implements Component{
private Component component;
public Decorator(Component component){
this.component = component;
}
public void operation(){
component.operation();
}
}
class ConcreteDecoratorA extends Decorator{
String addedState = "My name is ConcreteDecoratorA";
public ConcreteDecoratorA(Component component){
super(component);
}
public void operation(){
super.operation();
System.out.println(addedState);
}
}
class ConcreteDecoratorB extends Decorator{
public ConcreteDecoratorB(Component component){
super(component);
}
public void operation(){
super.operation();
this.addedBehavior();
}
public void addedBehavior(){
System.out.println("added Hello in ConcreteDecoratorB");
}
}
// 测试程序
class Test{
public static void main(String[] args){
Decorator decorator = new ConcreteDecoratorB(new ConcreteDecoratorA(new ConcreteComponent()));
decorator.operation(); // 调用不变,但已增加了新功能。
}
}
模式分析
一个装饰类的接口必须与被装饰类的接口保持一致,对于客户端来说,无论是装饰之前的对象还是装饰之后的对象都可以一致对待。尽量保持具体构件类 Component 作为一个“轻”类,也就是说不要把太多的逻辑和状态放在具体构件类中,可以通过装饰类对其进行扩展。如果只有一个具体构件类而没有抽象构件类,那么抽象修饰类可以作为具体构件类的直接子类。
与继承关系相比,关联关系的主要优势在于不会破坏类的封装性,而且继承是一种耦合度较大的静态关系,无法在程序运行时动态扩展。在软件开发阶段,关联关系虽然不会比继承关系减少编码量,但是到了软件维护阶段,由于关联关系使系统具有较好的松耦合性,因此使得系统更加容易维护。当然关联关系的缺点是比继承关系要创建更多的对象。
使用装饰模式来实现扩展比继承更加灵活,它以对客户透明的方式动态地给一个对象附加更多的责任。装饰模式可以在不需要创建更多子类的情况下,将对象的功能加以扩展。
优点
装饰模式与继承关系的目的都是要扩展对象的功能,但是装饰模式可以提供比继承更多的灵活性。可以通过一种动态的方式来扩展一个对象的功能,通过配置文件可以在运行时选择不同的装饰器,从而实现不同的行为。通过使用不同的具体装饰类以及这些装饰类的排列组合,可以创造出很多不同行为的组合。可以使用多个具体装饰类来装饰同一对象,得到功能更加强大的对象。具体构件类与具体装饰类可以独立变化,使用者可以根据需要增加新的具体构件类和具体装饰类,在使用时再对其进行组合,原有代码无需修改,符合开闭原则。
缺点
使用装饰模式进行系统设计时将产生很多小对象,这些对象的区别在于他们之间相互链接的方式有所不同,而不是他们的类或者属性值有所不同,同时还将产生很多具体装饰类。这些装饰类和小对象的产生将增加系统的复杂度,加大学习与理解的难度。这种比继承更加灵活机动的特性,也同时意味着装饰模式比继承更加易于出错,排错也很困难。对于多次装饰的对象,调试时可能需要逐级排查,较为繁琐。
适用场景
在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。
需要动态地给一个对象添加功能,这些功能也可以动态地被撤销。
不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展或维护的时候。
不能采用继承的情况主要有两类:系统中存在大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目爆炸性增长;类定义不能继承。