GoF设计模式——装饰器模式

h5打开以查看为什么需要装饰器模式？假设经营一家咖啡店，有基础咖啡和浓缩咖啡两种基底。顾客可以加牛奶、加糖、加珍珠……如果用继承来实现每一种组合，会得到MilkCoffee、SugarCoffee、MilkSugarCoffee、PearlMilkCoffee……每增加一种配料，类的数量就会翻倍。这就是组合爆炸问题。继承是静态的，编译时就确定了功能组合。但现实中，顾客的需求是动态的——今天加珍珠明天不加，同一个人上午要牛奶下午要燕麦奶。需要一种机制，能在运行时灵活地给对象"叠加"功能，而不是提前把所有组合都写死。装饰器模式正是为此而生：通过组合而非继承，在运行时动态地给对象添加额外功能。被装饰的对象和装饰器实现相同的接口，客户端完全感知不到自己拿到的是原始对象还是被层层包装后的对象。概念装饰器模式Decorator Pattern是一种结构型设计模式，核心思想是在不改变对象接口的前提下，动态地为对象添加额外职责。装饰器模式通过将原始对象放入一个"包装器"（装饰器）中来实现功能增强。装饰器与被装饰对象实现相同的接口，因此可以层层嵌套，形成一条装饰链。装饰器模式的主要角色有：Component（组件）：定义组件和装饰器共同实现的抽象接口ConcreteComponent（具体组件）：被装饰的原始对象，实现 Component 接口Decorator（装饰器）：持有 Component 引用的抽象类，实现 Component 接口，将所有调用委托给被装饰对象ConcreteDecorator（具体装饰器）：在委托调用的基础上添加新功能ConcreteComponent 是被装饰的原始对象。Decorator 持有一个 Component 引用（可以是 ConcreteComponent，也可以是已经被其他装饰器包装过的对象），并将调用委托给它。ConcreteDecorator 在委托前后添加自己的行为。由于装饰器本身也实现 Component 接口，所以可以层层嵌套，形成装饰链。可以把装饰器模式理解为穿衣服：人（ConcreteComponent）是基础，穿上 T 恤（ConcreteDecoratorA）是第一层装饰，再套上外套（ConcreteDecoratorB）是第二层。每加一层衣服，整体的"功能"就多一层（保暖、防风、好看），但人还是那个人，衣服之间也可以自由搭配、随意增减。实现基础实现装饰器模式的标准实现分为以下几个步骤：定义 Component 接口，声明组件和装饰器共同实现的方法实现 ConcreteComponent，提供基础功能定义 Decorator 抽象类，持有 Component 引用并委托调用实现 ConcreteDecorator，在委托前后添加新功能// 步骤1：定义组件接口 interface Component { void operation(); } // 步骤2：实现具体组件 class ConcreteComponent implements Component { public void operation() { System.out.println("基础功能"); } } // 步骤3：定义抽象装饰器 abstract class Decorator implements Component { protected Component component; public Decorator(Component component) { this.component = component; } public void operation() { component.operation(); // 委托给被装饰对象 } } // 步骤4：实现具体装饰器 class ConcreteDecoratorA extends Decorator { public ConcreteDecoratorA(Component component) { super(component); } public void operation() { super.operation(); // 先调用被装饰对象的功能 System.