装饰模式
装饰模式 (Decorator Pattern)，也称为包装器模式 (Wrapper Pattern)，是一种结构型设计模式。它允许你向一个现有的对象动态地添加新的功能，同时又不改变其结构。这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
核心思想：
动态地给一个对象添加一些额外的职责。
就增加功能来说，装饰模式相比生成子类更为灵活。
装饰者和被装饰者实现同一个接口，或者装饰者是抽象被装饰者的子类。
为什么需要装饰模式？
想象一下，你有一个咖啡店的系统。基础的咖啡有浓缩咖啡 (Espresso)、混合咖啡 (HouseBlend) 等。现在顾客可以要求加牛奶 (Milk)、摩卡 (Mocha)、豆浆 (Soy)、奶泡 (Whip) 等调料。
如果使用继承：
EspressoWithMilk
EspressoWithMocha
EspressoWithMilkAndMocha
HouseBlendWithMilk
...
这会导致类的数量急剧膨胀，难以管理和维护（类爆炸问题）。而且，如果你想动态地给一杯已经做好的咖啡加调料，继承就无能为力了。
装饰模式通过“包装”的方式，优雅地解决了这个问题。
装饰模式的参与者：
Component (组件接口):
定义了原始对象和装饰器对象的共同接口。
客户端代码将通过这个接口与对象进行交互。
例如：Beverage (饮品接口)
ConcreteComponent (具体组件):
实现了 Component 接口的类，是被装饰的原始对象。
例如：Espresso, HouseBlend (具体的饮品)
Decorator (抽象装饰类):
也实现了 Component 接口（或者继承自 Component 的抽象类）。
它持有一个 Component 对象的引用 (通常通过构造函数传入)。
它的主要职责是将请求传递给它所包装的 Component 对象，并且可以在传递请求之前或之后执行一些额外的操作。
例如：CondimentDecorator (调料装饰器抽象类)
ConcreteDecorator (具体装饰类):
继承自 Decorator (或实现 Component 接口并包含一个 Component)。
它向被包装的 Component 对象添加具体的功能。
例如：Milk, Mocha, Whip (具体的调料)
工作流程：
客户端创建一个 ConcreteComponent 对象。
如果需要添加功能，客户端将这个 ConcreteComponent 对象传递给一个 ConcreteDecorator 对象的构造函数，创建一个装饰后的对象。
可以重复步骤2，用一个装饰器包装另一个装饰器，形成一个装饰链。
客户端通过最外层的装饰器对象（它也实现了 Component 接口）调用方法。
请求会沿着装饰链逐层传递到最内层的 ConcreteComponent，并且每个装饰器都可以在这个过程中添加自己的行为。
一个简单的Java示例 (咖啡店):
// 1. Component (组件接口)
interface Beverage {
String getDescription();
double cost();
}
// 2. ConcreteComponent (具体组件)
class Espresso implements Beverage {
@Override
public String getDescription() {
return "Espresso";
}
@Override
public double cost() {
return 1.99;
}
}
class HouseBlend implements Beverage {
@Override
public String getDescription() {
return "House Blend Coffee";
}
@Override
public double cost() {
return 0.89;
}
}
// 3. Decorator (抽象装饰类)
abstract class CondimentDecorator implements Beverage {
protected Beverage beverage; // 被包装的饮品对象
public CondimentDecorator(Beverage beverage) {
this.beverage = beverage;
}
// 通常，getDescription() 在抽象装饰器中可能是抽象的，或者直接委托
// 这里我们选择让具体的装饰器来组合描述
@Override
public abstract String getDescription();
// cost() 也由具体装饰器实现
}
// 4. ConcreteDecorator (具体装饰类)
class Milk extends CondimentDecorator {
public Milk(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Milk";
}
@Override
public double cost() {
return beverage.cost() + 0.10;
}
}
class Mocha extends CondimentDecorator {
public Mocha(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Mocha";
}
@Override
public double cost() {
return beverage.cost() + 0.20;
}
}
class Whip extends CondimentDecorator {
public Whip(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Whip";
}
@Override
public double cost() {
return beverage.cost() + 0.15;
}
}
// 客户端代码
public class StarbuzzCoffee {
public static void main(String[] args) {
Beverage beverage = new Espresso();
System.out.println(beverage.getDescription() + " $" + beverage.cost());
// Output: Espresso $1.99
Beverage beverage2 = new HouseBlend();
beverage2 = new Mocha(beverage2); // 用Mocha装饰
beverage2 = new Milk(beverage2); // 再用Milk装饰
beverage2 = new Whip(beverage2); // 再用Whip装饰
System.out.println(beverage2.getDescription() + " $" + String.format("%.2f", beverage2.cost()));
// Output: House Blend Coffee, Mocha, Milk, Whip $1.34
Beverage beverage3 = new Espresso();
beverage3 = new Milk(beverage3);
beverage3 = new Milk(beverage3); // 加两份牛奶
beverage3 = new Whip(beverage3);
System.out.println(beverage3.getDescription() + " $" + String.format("%.2f", beverage3.cost()));
// Output: Espresso, Milk, Milk, Whip $2.34
}
}
优点：
比继承更灵活： 可以在运行时动态地添加或删除对象的职责，而不需要修改现有类的代码。
避免类爆炸： 通过组合的方式，可以避免因各种功能组合而导致大量子类的产生。
职责分离： 每个装饰器只关心添加特定的功能，使得类的职责更加单一。
符合开闭原则： 对扩展开放（可以添加新的装饰器），对修改关闭（不需要修改现有组件或装饰器）。
装饰器和被装饰的对象可以独立变化： 只要它们都遵循共同的接口。
缺点：
产生许多小对象： 系统中可能会出现很多小的装饰器对象，如果过度使用，会增加系统的复杂性。
调试困难： 由于涉及到多层包装，在调试时追踪问题可能会比较复杂。
接口一致性： 装饰器和被装饰对象必须具有相同的接口。如果被装饰对象的接口很庞大，那么装饰器的实现也会变得复杂。
何时使用装饰模式？
当你希望在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
当你希望用比继承更灵活的方式来扩展对象的功能。
当通过子类化扩展会产生大量独立的扩展，导致类数量爆炸时。
当一个类的定义被隐藏，或者因其他原因无法通过子类化扩展时（例如，final 类）。
实际应用场景举例：
Java I/O 类库： FileInputStream (ConcreteComponent) 可以被 BufferedInputStream (ConcreteDecorator) 包装以增加缓冲功能