装饰器模式

为什么需要装饰器模式？

我们要买奶茶，希望加红豆和布丁。考虑如何实现这个对象的构造：

1. 把红豆和布丁作为两个成员变量：无法动态的添加成员变量
2. 创建一个成员变量表示“添加列表”，添加红豆和布丁作为元素：我们的奶茶需要一些修饰方法与红豆和布丁有关
3. 红豆和布丁作为两个独立的类，继承奶茶：如果一杯奶茶既添加了红豆又添加了布丁则无法实现这种效果

可见普通的组合和继承都无法很好的实现我们的要求。

装饰器模式概念

• Component为统一接口，也是装饰类和被装饰类的基本类型。
• ConcreteComponent为具体实现类，也是被装饰类，他本身是个具有一些功能的完整的类。
• Decorator是装饰类，实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例，并可以通过构造函数初始化。而Decorator本身，通常采用默认实现，他的存在仅仅是一个声明：我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。
• ConcreteDecorator是具体的装饰产品类，每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent，从而对其进行装饰。

装饰器模式为什么需要如此结构？

1. 装饰器模式最核心的功能在于具体的装饰器类可以重写具体实现的一些方法（其中会调用具体实现类的方法实现，不是通过super，而是构造器传入的参数作为成员变量），这样要求这两者必须处于同一个继承体系之内，所以最上层需要一个公共接口来联系装饰器和实现类
2. 具体的装饰器类需要一个抽象的装饰器父类来做规范，应该重写哪些方法

代码

//基础接口
public interface Component {
    
    public void biu();
}
//具体实现类
public class ConcretComponent implements Component {

    public void biu() {
        
        System.out.println("biubiubiu");
    }
}
//装饰类
public class Decorator implements Component {

    public Component component;
    
    public Decorator(Component component) {
        
        this.component = component;
    }
    
    public void biu() {
        
        this.component.biu();
    }
}
//具体装饰类
public class ConcreteDecorator extends Decorator {

    public ConcreteDecorator(Component component) {

        super(component);
    }

    public void biu() {
        
        System.out.println("ready?go!");
        this.component.biu();
    }
}

有哪些地方用到了装饰器模式？

javaIO，swing图形界面构件等