《设计模式》之装饰者模式

《设计模式》之装饰者模式

看了很多博文，感觉自己都没有彻底理解清楚装饰者模式，总是感觉还差点什么。

定义

装饰者模式：动态地给一个对象添加一些额外的职责，就增加功能来说，Decorator模式比生成子类更为灵活。

Decorator模式的工作原理是：可以创建始于Decorator对象（负责新的功能的对象）终于原对象的一个对象“链”。

装饰者模式隐含的是通过一条条装饰链去实现具体对象，每一条装饰链都始于一个Componet对象，每个装饰者对象后面紧跟着另一个装饰者对象，而对象链终于ConcreteComponet对象。

装饰模式的类图如下：

在装饰模式中的角色有：

　　●　　抽象构件(Component)角色：定义ConcreteComponent和Decorator类要实现的方法，简单来说如果一个类继承于该类就具有装饰或被装饰能力。

　　●　　具体构件(ConcreteComponent)角色：让Decorator对象为自己添加功能。有时候使用ConcreteComponent的派生类提供核心功能，在这种情况就是用ConcreteComponent替代了Component的功能，而且装饰者是继承于ConcreteComponent的子类。

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

　　●　　具体装饰(ConcreteDecorator)角色：具有特定装饰功能的类，用来装饰ConcreteComponent类。

实例

装饰者模式顾名思义就是用来装饰物件的，其实像我们生活中礼品的装饰就是将一个礼物包裹的更加赏心悦目，更符合要送给对象和心意。OK现在想想更加接近编程的例子，我想大家都了解IP报文，IP报文是通过很多报头组成的，而且每个报头都有其作用（例如：数据包的目的地址和源地址）。每次当我们要传输数据的时候，我们电脑将根据TCP/IP报文格式去装饰我们要传输的数据，好啦装饰者模式出现啦。

现在我们定义了ConcreteComponent类，它是我们要发送的数据在发送过程我们可以随意添加报头（注意：IP报文格式是固定），但数据本身毫不关心究竟要添加什么报头和怎样添加，SourAddress和DestAddress是我们的装饰者负责给我们数据添加报头，装饰者只关心自己添加的功能，并不关心其他装饰者的实现。

源码

抽象组件类

package com.wrh.designmodel;
/*
 * 抽象组件类
 * */
public abstract class Component {
    abstract public void addMessage();
}

具体组件类

package com.wrh.designmodel;
//即被装饰者
public class ConcreteComponent extends Component {
    @Override
    public void addMessage() {
        System.out.println("我是消息体");
    }

}

抽象装饰类

package com.wrh.designmodel;

public abstract class MessageDecorate extends Component {
    //有一个Component实例
    private Component component;
    public MessageDecorate(Component component){
        this.component=component;
    }

}

具体装饰类：添加源地址

package com.wrh.designmodel;

public class SourceAddressDecorate extends MessageDecorate{
    private Component component;
    public SourceAddressDecorate(Component component) {
        super(component);
        this.component=component;
    }
    @Override
    public void addMessage() {
        component.addMessage();
        System.out.println("添加原地址");

    }

}

具体装饰类：添加目的地址

package com.wrh.designmodel;

public class DestinationAddressDecorate extends MessageDecorate{
    private Component component;
    public DestinationAddressDecorate(Component component) {
        super(component);
        this.component=component;
    }

    @Override
    public void addMessage() {
        component.addMessage();
        System.out.println("添加目的地址");
    }

}

客服端

package com.wrh.designmodel;

public class Test {

    public static void main(String[] args) {
        //先定义一个被装饰者
        Component component=new ConcreteComponent();
        //开始装饰
        //第一步：开始装饰源地址
        SourceAddressDecorate source=new SourceAddressDecorate(component);
        //第二步：开始装饰目的地址
        DestinationAddressDecorate destination=new DestinationAddressDecorate(source);
        //上面两步装饰的第二种写法如下
        //DestinationAddressDecorate destination=new DestinationAddressDecorate(new SourceAddressDecorate(new ConcreteComponent))
        destination.addMessage();
    }

}

相信上面这个例子比较好理解，关于装饰者的例子，个人觉得这篇博文中举得例子也比较好：http://blog.csdn.net/lansuiyun/article/details/11714957

总结

装饰者模式的应用场景：

1、 想透明并且动态地给对象增加新的职责的时候。

2、 给对象增加的职责，在未来存在增加或减少可能。

3、 用继承扩展功能不太现实的情况下，应该考虑用组合的方式。

装饰者模式的优点：

1、 通过组合而非继承的方式，实现了动态扩展对象的功能的能力。

2、 有效避免了使用继承的方式扩展对象功能而带来的灵活性差，子类无限制扩张的问题。

3、 充分利用了继承和组合的长处和短处，在灵活性和扩展性之间找到完美的平衡点。

4、 装饰者和被装饰者之间虽然都是同一类型，但是它们彼此是完全独立并可以各自独立任意改变的。

5、 遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

装饰者模式的缺点：

1、 装饰链不能过长，否则会影响效率。

2、 因为所有对象都是继承于Component,所以如果Component内部结构发生改变，则不可避免地影响所有子类(装饰者和被装饰者)，也就是说，通过继承建立的关系总是脆弱地，如果基类改变，势必影响对象的内部，而通过组合(Decoator HAS A Component)建立的关系只会影响被装饰对象的外部特征。

3、只在必要的时候使用装饰者模式，否则会提高程序的复杂性，增加系统维护难度。

参考地址
1：http://www.cnblogs.com/rush/archive/2011/05/08/Decorator_DesignPattern_NETFramework.html

2：http://www.cnblogs.com/java-my-life/archive/2012/04/20/2455726.html