设计模式——装饰者模式

装饰者模式：装饰模式（Decorator）也叫包装器模式（Wrapper）。GOF在《设计模式》一书中给出的定义为：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。




1) 抽象构件角色（Component）：定义一个抽象接口，以规范准备接收附加责任的对象。

2) 具体构件角色(Concrete Component)：这是被装饰者，定义一个将要被装饰增加功能的类。

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

4) 具体装饰角色(Concrete Decorator)：负责给构件添加增加的功能。

要点： 装饰者与被装饰者拥有共同的超类，继承的目的是继承类型，而不是行为

问题: 说装饰者模式比用继承会更富有弹性,在类图中不是一样用到了继承了吗?

说明: 装饰者和被装饰者之间必须是一样的类型,也就是要有共同的超类。在这里应用继承并不是实现方法的复制,而是实现类型的匹配。因为装饰者和被装饰者是同一个类型,因此装饰者可以取代被装饰者,这样就使被装饰者拥有了装饰者独有的行为。根据装饰者模式的理念,我们可以在任何时候,实现新的装饰者增加新的行为。如果是用继承,每当需要增加新的行为时,就要修改原程序了。

装饰者包含一个超类的对象，这样，可以在被装饰者行为前或者行为后加上新的行为，甚至取代原有的行为

装饰者会使程序中出现很多小类，增加使用难度

使用场景：对象由主体+许多可选的部件或者功能构成，使用继承或者接口会产生很多类，且很难扩展。例如，现在需要一个汉堡，主体是鸡腿堡，可以选择添加生菜、酱、辣椒等等许多其他的配料，这种情况下就可以使用装饰者模式。

假设我们现在正在开发一个留言板的应用，为了得到用户的留言，我们可以这样做：

package com.softeem.decorator;

/**

 * @author leno 用户留言板处理的接口

 */

public interface MessageBoardHandler {

   public String filter(String msg);

}

package com.softeem.decorator;

/**

 * @author leno 用户留言板的具体实现

 */

public class MessageBoard implements MessageBoardHandler {

   public String filter(String msg) {

      return "处理留言板上的内容：" + msg;

   }

}

package com.softeem.decorator;

/**

 * @author leno 客户端测试

 */

public class Test {

   public static void main(String[] args) {

      MessageBoardHandler mb = new MessageBoard();

      String content = mb.filter("一定要学好装饰模式！");

      System.out.println(content);

   }

}

这个代码是很浅显易懂的。但是后来我们增加了需求，需要我们得到留言板上的内容后能够过滤掉HTML标签和政治敏感的字眼，这时候我们该怎么办呢？修改Content类还是扩展Content类？修改Conent类显然不是个好主意，因为我们有些地方可能还需要最原始的留言。那么继承并扩展Content类呢？也不太可行，为什么呢？一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。我们这里主要考虑到第一种情况。大家想想，过滤掉HTML标签和政治敏感的字眼这两个功能有先后顺序问题。不同的顺序我们就要做做不同的类来实现。如果类似这样的功能又增加了几个，排列组合起来是很可怕的。那如何是好呢？你要停下来好好思索一下了。

package com.softeem.decorator;

/**

 * @author leno 装饰角色

 */

public class MessageBoardDecorator implements MessageBoardHandler {

   private MessageBoardHandler handler;

   public MessageBoardDecorator(MessageBoardHandler handler) {

      super();

      this.handler = handler;

   }

   public String filter(String msg) {

      return handler.filter(msg);

   }

}

package com.softeem.decorator;

/**

 * @author leno 具体装饰角色，增加过滤掉HTML标签的功能

 */

public class HtmlFilter extends MessageBoardDecorator {

   public HtmlFilter(MessageBoardHandler handler) {

      super(handler);

   }

   public String filter(String content) {

      String temp = super.filter(content);

      temp += "^^过滤掉HTML标签!^^";

      return temp;

   }

}

package com.softeem.decorator;

/**

 * @author leno 具体装饰角色，增加过滤掉政治敏感字眼的功能

 */

public class SensitiveFilter extends MessageBoardDecorator {

   public SensitiveFilter(MessageBoardHandler handler) {

      super(handler);

   }

   public String filter(String content) {

      String temp = super.filter(content);

      temp += "^^过滤掉政治敏感的字眼!^^";

      return temp;

   }

}

package com.softeem.decorator;

/**

 * @author leno 客户端测试

 */

public class Test {

   public static void main(String[] args) {

      MessageBoardHandler mb = new MessageBoard();

      String content = mb.filter("一定要学好装饰模式！");

      System.out.println(content);

      mb = new HtmlFilter(new SensitiveFilter(new MessageBoard()));

      content = mb.filter("一定要学好装饰模式！");

      System.out.println(content);

   }

}

J***A中IO流的设计就大量运用了装饰模式。看看我们熟悉的代码:

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(“..”)));

层层包装，增强功能。这就是装饰模式的要旨。

装饰者模式的应用场景：

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

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

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

装饰者模式的优点：

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

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

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

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

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

装饰者模式的缺点：

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

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

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

转自http://www.cnblogs.com/rush/archive/2011/05/08/Decorator_DesignPattern_NETFramework.html