模式设计——装饰模式

装饰模式又名包装(Wrapper)模式。装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案。

一、装饰模式的结构

装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。换言之,客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下,将对象的功能加以扩展。

装饰模式的类图如下:

 

在装饰模式中的角色有:

抽象构件(Component)角色:给出一个抽象接口,以规范准备接收附加责任的对象。

具体构件(ConcreteComponent)角色:定义一个将要接收附加责任的类。

装饰(Decorator)角色:持有一个构件(Component)对象的实例,并定义一个与抽象构件接口一致的接口。

具体装饰(ConcreteDecorator)角色:负责给构件对象“贴上”附加的责任。

源代码

抽象构件角色

public interface Component {

public void sampleOperation();

}

具体构件角色

public class ConcreteComponent implements Component {

 

@Override

public void sampleOperation() {

// 写相关的业务代码

}

 

}

装饰角色

public class Decorator implements Component{

private Component component;

public Decorator(Component component){

this.component = component;

}

 

@Override

public void sampleOperation() {

// 委派给构件

component.sampleOperation();

}

}

具体装饰角色

public class ConcreteDecoratorA extends Decorator {

 

public ConcreteDecoratorA(Component component) {

super(component);

}

@Override

public void sampleOperation() {

     super.sampleOperation();

// 写相关的业务代码

}

}

public class ConcreteDecoratorB extends Decorator {

 

public ConcreteDecoratorB(Component component) {

super(component);

}

@Override

public void sampleOperation() {

    super.sampleOperation();

// 写相关的业务代码

}

}

二、实例

孙悟空有七十二般变化,他的每一种变化都给他带来一种附加的本领。他变成鱼儿时,就可以到水里游泳;他变成鸟儿时,就可以在天上飞行。

本例中,Component的角色便由鼎鼎大名的齐天大圣扮演;ConcreteComponent的角色属于大圣的本尊,就是猢狲本人;Decorator的角色由大圣的七十二变扮演。而ConcreteDecorator的角色便是鱼儿、鸟儿等七十二般变化。

 

源代码

抽象构件角色“齐天大圣”接口定义了一个move()方法,这是所有的具体构件类和装饰类必须实现的。

//大圣的尊号

public interface TheGreatestSage {

public void move();

}

具体构件角色“大圣本尊”猢狲类

public class Monkey implements TheGreatestSage {

 

@Override

public void move() {

//代码

System.out.println("Monkey Move");

}

 

}

抽象装饰角色“七十二变”

public class Change implements TheGreatestSage {

private TheGreatestSage sage;

public Change(TheGreatestSage sage){

this.sage = sage;

}

@Override

public void move() {

// 代码

sage.move();

}

 

}

具体装饰角色“鱼儿”

public class Fish extends Change {

public Fish(TheGreatestSage sage) {

super(sage);

}

 

@Override

public void move() {

// 代码

System.out.println("Fish Move");

}

}

具体装饰角色“鸟儿”

public class Bird extends Change {

public Bird(TheGreatestSage sage) {

super(sage);

}

 

@Override

public void move() {

// 代码

System.out.println("Bird Move");

}

}

客户端类

public class Client {

 

public static void main(String[] args) {

TheGreatestSage sage = new Monkey();

// 第一种写法

TheGreatestSage bird = new Bird(sage);

TheGreatestSage fish = new Fish(bird);

// 第二种写法

//TheGreatestSage fish = new Fish(new Bird(sage));

fish.move();

}

 

}

“大圣本尊”是ConcreteComponent类,而“鸟儿”、“鱼儿”是装饰类。要装饰的是“大圣本尊”,也即“猢狲”实例。

上面的例子中,系统把大圣从一只猢狲装饰成了一只鸟儿(把鸟儿的功能加到了猢狲身上),然后又把鸟儿装饰成了一条鱼儿(把鱼儿的功能加到了猢狲+鸟儿身上,得到了猢狲+鸟儿+鱼儿)。

 

如上图所示,大圣的变化首先将鸟儿的功能附加到了猢狲身上,然后又将鱼儿的功能附加到猢狲+鸟儿身上。

三、装饰模式的简化

大多数情况下,装饰模式的实现都要比上面给出的示意性例子要简单。

如果只有一个ConcreteComponent类,那么可以考虑去掉抽象的Component类(接口),把Decorator作为一个ConcreteComponent子类。如下图所示:

 

如果只有一个ConcreteDecorator类,那么就没有必要建立一个单独的Decorator类,而可以把DecoratorConcreteDecorator的责任合并成一个类。甚至在只有两个ConcreteDecorator类的情况下,都可以这样做。如下图所示:

 

四、透明性的要求

装饰模式对客户端的透明性要求程序不要声明一个ConcreteComponent类型的变量,而应当声明一个Component类型的变量。

用孙悟空的例子来说,必须永远把孙悟空的所有变化都当成孙悟空来对待,而如果把老孙变成的鱼儿当成鱼儿,而不是老孙,那就被老孙骗了,而这时不应当发生的。下面的做法是对的:

TheGreatestSage sage = new Monkey();

TheGreatestSage bird = new Bird(sage);

而下面的做法是不对的:

Monkey sage = new Monkey();

Bird bird = new Bird(sage);

五、半透明的装饰模式

然而,纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下,增强所考虑的类的性能。在增强性能的时候,往往需要建立新的公开的方法。即便是在孙大圣的系统里,也需要新的方法。比如齐天大圣类并没有飞行的能力,而鸟儿有。这就意味着鸟儿应当有一个新的fly()方法。再比如,齐天大圣类并没有游泳的能力,而鱼儿有,这就意味着在鱼儿类里应当有一个新的swim()方法。

这就导致了大多数的装饰模式的实现都是“半透明”的,而不是完全透明的。换言之,允许装饰模式改变接口,增加新的方法。这意味着客户端可以声明ConcreteDecorator类型的变量,从而可以调用ConcreteDecorator类中才有的方法:

TheGreatestSage sage = new Monkey();

Bird bird = new Bird(sage);

bird.fly();

半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口,也可以通过改写一个或几个方法,或增加新的方法来增强或改变所考虑的类的功能。大多数的装饰模式实际上是半透明的装饰模式,这样的装饰模式也称做半装饰、半适配器模式。

六、装饰模式的优点

1)装饰模式与继承关系的目的都是要扩展对象的功能,但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”,或者除掉一个不需要的“装饰”。继承关系则不同,继承关系是静态的,它在系统运行前就决定了。

2)通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。

七、装饰模式的缺点

由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。