模式设计——装饰模式

模式设计——装饰模式

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

1、装饰模式的结构

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

装饰模式的类图以下：

 

在装饰模式中的角色有：

●抽象构件(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();

// 写相关的业务代码

}

}

2、实例

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

本例中，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类，而“鸟儿”、“鱼儿”是装饰类。要装饰的是“大圣本尊”，也即“猢狲”实例。

上面的例子中，系统把大圣从一只猢狲装饰成了一只鸟儿（把鸟儿的功能加到了猢狲身上），而后又把鸟儿装饰成了一条鱼儿（把鱼儿的功能加到了猢狲+鸟儿身上，获得了猢狲+鸟儿+鱼儿）。

 

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

3、装饰模式的简化

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

若是只有一个ConcreteComponent类，那么能够考虑去掉抽象的Component类（接口），把Decorator做为一个ConcreteComponent子类。以下图所示：

 

若是只有一个ConcreteDecorator类，那么就没有必要创建一个单独的Decorator类，而能够把Decorator和ConcreteDecorator的责任合并成一个类。甚至在只有两个ConcreteDecorator类的状况下，均可以这样作。以下图所示：

 

4、透明性的要求

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

用孙悟空的例子来讲，必须永远把孙悟空的全部变化都当成孙悟空来对待，而若是把老孙变成的鱼儿当成鱼儿，而不是老孙，那就被老孙骗了，而这时不该当发生的。下面的作法是对的：

TheGreatestSage sage = new Monkey();

TheGreatestSage bird = new Bird(sage);

而下面的作法是不对的：

Monkey sage = new Monkey();

Bird bird = new Bird(sage);

5、半透明的装饰模式

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

这就致使了大多数的装饰模式的实现都是“半透明”的，而不是彻底透明的。换言之，容许装饰模式改变接口，增长新的方法。这意味着客户端能够声明ConcreteDecorator类型的变量，从而能够调用ConcreteDecorator类中才有的方法：

TheGreatestSage sage = new Monkey();

Bird bird = new Bird(sage);

bird.fly();

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

6、装饰模式的优势

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

（2）经过使用不一样的具体装饰类以及这些装饰类的排列组合，设计师能够创造出不少不一样行为的组合。

7、装饰模式的缺点

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