设计模式-装饰模式
装饰模式
装饰模式 (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 {@Overridepublic String getDescription() {return "Espresso";} @Overridepublic double cost() {return 1.99;} } class HouseBlend implements Beverage {@Overridepublic String getDescription() {return "House Blend Coffee";} @Overridepublic double cost() {return 0.89;} } // 3. Decorator (抽象装饰类) abstract class CondimentDecorator implements Beverage {protected Beverage beverage; // 被包装的饮品对象 public CondimentDecorator(Beverage beverage) {this.beverage = beverage;} // 通常,getDescription() 在抽象装饰器中可能是抽象的,或者直接委托// 这里我们选择让具体的装饰器来组合描述@Overridepublic abstract String getDescription();// cost() 也由具体装饰器实现 } // 4. ConcreteDecorator (具体装饰类) class Milk extends CondimentDecorator {public Milk(Beverage beverage) {super(beverage);} @Overridepublic String getDescription() {return beverage.getDescription() + ", Milk";} @Overridepublic double cost() {return beverage.cost() + 0.10;} } class Mocha extends CondimentDecorator {public Mocha(Beverage beverage) {super(beverage);} @Overridepublic String getDescription() {return beverage.getDescription() + ", Mocha";} @Overridepublic double cost() {return beverage.cost() + 0.20;} } class Whip extends CondimentDecorator {public Whip(Beverage beverage) {super(beverage);} @Overridepublic String getDescription() {return beverage.getDescription() + ", Whip";} @Overridepublic 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) 包装以增加缓冲功能