看看我们的示例代码吧：
package 装饰模式;
//被装饰的类的抽象父类
public abstract class Component {
public abstract void operation();
}
package 装饰模式;
//需要被装饰的具体类
public class Hourse extends Component {
@Override
public void operation() {
System.out.println("这是一个普通的屋子。");
}
}
package 装饰模式;
//抽象装饰类
public abstract class Decorator extends Component {
//Component对象的引用
private Component component;
public Decorator(Component component) {
this.component=component;
}
@Override
public void operation() {
this.component.operation();
}
}
package 装饰模式;
//具体装饰类
public class DoorDecorator extends Decorator {
public DoorDecorator(Component component){
super(component);
}
@Override
public void operation() {
super.operation();
System.out.println("装饰了屋子的门，屋子变漂亮了。");
}
}
package 装饰模式;
//具体装饰类
public class FurnitureDecorator extends Decorator{
public FurnitureDecorator(Component component) {
super(component);
}
@Override
public void operation() {
super.operation();
System.out.println("装饰了屋子的家具，屋子变更漂亮了。");
}
}
package 装饰模式;
//客户端
public class Client {
public static void main(String[]args){
Component hourse=new Hourse();
hourse.operation();
//给屋子的门进行装饰
hourse=new DoorDecorator(hourse);
hourse.operation();
//给屋子的家具进行装饰
hourse=new FurnitureDecorator(hourse);
hourse.operation();
}
}
输出：
这是一个普通的屋子。
这是一个普通的屋子。
装饰了屋子的门，屋子变漂亮了。
这是一个普通的屋子。
装饰了屋子的门，屋子变漂亮了。
装饰了屋子的家具，屋子变更漂亮了。
关于装饰模式的总结：
1、通过采用组合、而非继承的手法，Decorator模式实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。
2、Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于
Component类应该透明——换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能。
3、Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component
对象。我的理解是：当我们实例化一个Component对象后，要给这个对象扩展功能，这时我们把这个Component对象当作参数传给Decorator的子类的构造函数——也就是扩展方法的功能类。对于引用类型传参时，实际上只是传递对象的地址，也就是在原来的对象上扩展功能。
4、Decorator模式并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。Decorator是在运行时对功能进行组合。
