Decorator模式个人理解

爪哇猪 — Mon, 12 Oct 2009 08:50:00 GMT

首先说说这个模式产生的背景，需求，或者是一直被<<设计模式精解>>里提到的场景。
起初的需求是打印一个订单票据，然后又要求给加上一个抬头和一个脚注，再然后又要求抬头和脚注的数量不止一个。

其实说一下这个模式在技术上的一些要点：
先上一段<<设计模式精解>>里的代码：
abstract class Component {
    public abstract void prtTicket();
}

class SalesTicket extends Component {
   public void prtTicket() {
       System.out.println("Sales Ticket");
   }
}

class Decorator extends Component {
    private Component myComp;

    public Decorator(Component myC) {
        myComp = myC;
    }

    public void prtTicket() {
        if(myComp != null)
            myComp.prtTicket();
    }
}

class Header1 extends Decorator {

   public Header1(Component myC) {
       super(myC);
   }

   public void prtTicket() {
       System.out.println("Header 1");
       super.prtTicket();
   }
}

class Footer1 extends Decorator {

   public Footer1(Component myC) {
       super(myC);
   }

   public void prtTicket() {
       super.prtTicket();
       System.out.println("Footer 1");
   }
}

class Main {

   public static void main(String[] args) {
       new Header1(new Footer1(new SalesTicket())).prtTicket();
   }
}
其中，SalesTicket是被包装的对象，也就是核心功能，Decorator是围绕着这个核心功能所要添加的附加功能的抽象类。每个具体的附加功能类都继承Decorator这个类。这样做有两点意义：
1.因为Decorator是继承或实现了核心功能类所继承或实现的父类，这样通过继承Decorator，使附加功能和核心功能的接口一致。
2.将Decorator类的构造函数定义成只接受一个类型为Component类参数的方法，这样使得附加功能必须找到一个核心功能将其包装，也就是说附加功能类是不能单独存在的，必须含有一个核心功能类。

扩展：
为Decorator类及其所有子类添加无参构造函数，将Main改写一下：
class Main {

   public static void main(String[] args) {
       new Header1(new Footer1()).prtTicket();
   }
}
这样不包装核心功能可以直接使用附加功能，换句话说，不存在附加功能或核心功能，每个类既可以当附加功能也可以当核心功能。

最后说一下个人对这个模式的理解：
Decorate，翻译成中文意思是装饰，加了个-or就变成装饰者或者叫装饰器。既然叫装饰器，就是要对需要装饰的东西进行包装，改进，使其功能要比原来更多更好，而且既然是装饰，那就肯定不是主要的，核心的功能，只不过是锦上添花而已，不能喧宾夺主。比如说，原本一台好好的打印机，经过装饰后变成了一台“可以打印的”洗衣机，这花添的就大了点，虽说原来的功能还保留着，但是我想这应该不是这个模式提出者的初衷。

爪哇猪 2009-10-12 16:50 发表评论

语源科技BlogJava-java人

Decorator模式个人理解