装饰器模式通过组合动态扩展对象功能，遵循开闭原则。以咖啡为例，SimpleCoffee为基础组件，MilkDecorator和SugarDecorator作为具体装饰器，通过层层包裹添加新行为，避免类爆炸，实现运行时灵活组合，适用于功能可插拔、需动态增删职责的场景。
在Java中实现装饰器模式，核心在于通过组合而非继承的方式，动态地为一个对象添加新的职责或行为。它允许你将这些新的功能“包裹”在现有对象之外，而无需修改其原始代码，这在我看来，是遵循开闭原则（Open/Closed Principle）的一种优雅实践。简单来说，就是给一个对象穿上不同的“衣服”，每件衣服都赋予它新的能力，而且这些“衣服”可以层层叠加。
解决方案
实现装饰器模式，通常需要定义一个组件接口、一个或多个具体组件、一个抽象装饰器以及多个具体装饰器。以下是一个咖啡订单的例子，演示如何为一杯简单的咖啡添加牛奶和糖：
1. 定义组件接口 (Component Interface)
这是所有具体组件和装饰器都将实现的共同接口，定义了它们的核心行为。
立即学习“Java免费学习笔记（深入）”；
public interface Coffee {
String getDescription(); // 获取描述
double getCost(); // 获取价格
}2. 实现具体组件 (Concrete Component)
这是我们要装饰的原始对象，它实现了组件接口。
public class SimpleCoffee implements Coffee {
@Override
public String getDescription() {
return "纯咖啡";
}
@Override
public double getCost() {
return 5.0;
}
}3. 创建抽象装饰器 (Abstract Decorator)
这是一个抽象类，它也实现了组件接口，并包含一个对组件对象的引用。所有具体的装饰器都将继承这个抽象类。
public abstract class CoffeeDecorator implements Coffee {
protected Coffee decoratedCoffee; // 引用被装饰的对象
public CoffeeDecorator(Coffee decoratedCoffee) {
this.decoratedCoffee = decoratedCoffee;
}
// 默认实现，委托给被装饰的对象
@Override
public String getDescription() {
return decoratedCoffee.getDescription();
}
@Override
public double getCost() {
return decoratedCoffee.getCost();
}
}4. 实现具体装饰器 (Concrete Decorators)
这些类继承自抽象装饰器，并添加新的行为或修改现有行为。
public class MilkDecorator extends CoffeeDecorator {
public MilkDecorator(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
@Override
public String getDescription() {
return decoratedCoffee.getDescription() + ", 加牛奶";
}
@Override
public double getCost() {
return decoratedCoffee.getCost() + 2.0; // 牛奶加2元
}
}
public class SugarDecorator extends CoffeeDecorator {
public SugarDecorator(Coffee decoratedCoffee) {
super(decoratedCoffee);
}
@Override
public String getDescription() {
return decoratedCoffee.getDescription() + ", 加糖";
}
@Override
public double getCost() {
return decoratedCoffee.getCost() + 1.0; // 糖加1元
}
}5. 使用示例
现在，我们可以动态地组合这些组件和装饰器来创建不同口味的咖啡。
public class CoffeeShop {
public static void main(String[] args) {
// 一杯纯咖啡
Coffee coffee = new SimpleCoffee();
System.out.println("订单: " + coffee.getDescription() + ", 价格: " + coffee.getCost() + "元");
// 输出: 订单: 纯咖啡, 价格: 5.0元
// 加牛奶的咖啡
coffee = new MilkDecorator(coffee); // 用牛奶装饰纯咖啡
System.out.println("订单: " + coffee.getDescription() + ", 价格: " + coffee.getCost() + "元");
// 输出: 订单: 纯咖啡, 加牛奶, 价格: 7.0元
// 再加糖的咖啡 (在加牛奶的咖啡基础上)
coffee = new SugarDecorator(coffee); // 用糖装饰加牛奶的咖啡
System.out.println("订单: " + coffee.getDescription() + ", 价格: " + coffee.getCost() + "元");
// 输出: 订单: 纯咖啡, 加牛奶, 加糖, 价格: 8.0元
// 另一种组合：先加糖再加牛奶
Coffee anotherCoffee = new SugarDecorator(new MilkDecorator(new SimpleCoffee()));
System.out.println("订单: " + anotherCoffee.getDescription() + ", 价格: " + anotherCoffee.getCost() + "元");
// 输出: 订单: 纯咖啡, 加牛奶, 加糖, 价格: 8.0元
}
}从上面的例子可以看出，通过一层层地包裹，我们可以在运行时灵活地为
SimpleCoffee对象添加新的功能，而无需修改
SimpleCoffee类本身，也避免了为每种组合（如
MilkCoffee,
SugarCoffee,
MilkSugarCoffee）创建大量子类。
为什么选择装饰器模式？它解决了哪些Java开发中的痛点？
说实话，在我刚接触面向对象设计的时候，遇到需要给一个对象添加额外功能时，我的第一反应往往是继承。比如，如果我有一个
Car类，要增加一个“GPS功能”，我可能会创建一个
GPSCar继承自
Car。但如果还要“天窗功能”呢？
SunroofCar？那如果既要GPS又要天窗呢？
GPSSunroofCar？这很快就会导致一个“类爆炸”的问题，尤其是在功能组合非常多的情况下。这种继承链会变得异常复杂且僵硬，一旦需要添加或移除某个功能，整个继承体系都可能受到影响。
dmSOBC SHOP网店系统由北京时代胜腾信息技术有限公司（http://www.webzhan.com）历时6个月开发完成，本着简单实用的理念，商城在功能上摒弃了外在装饰的一些辅助功能，尽可能的精简各项模块开发，做到有用的才开发，网店V1.0.0版本开发完成后得到了很多用户的使用并获得了好评，公司立即对网店进行升级，其中包括修正客户提出的一些意见和建议，现对广大用户提供免费试用版本，如您在使用
装饰器模式恰恰解决了这个痛点。它提供了一种比继承更灵活的替代方案，可以在运行时动态地给对象添加职责。对我来说，它最核心的价值在于：
- 避免类爆炸和僵硬的继承体系： 它通过组合而非继承来扩展功能，这意味着你不需要为每一种功能组合都创建新的子类。这让我的代码库保持更小的规模，更容易维护。
- 运行时动态扩展： 继承是在编译时就确定了对象的行为，一旦编译完成，你就不能再改变其功能。而装饰器模式允许你在程序运行时，根据需要给对象添加或移除功能，这提供了极大的灵活性，特别适用于那些功能组合多变或需要根据用户选择动态调整的场景。
- 遵循开闭原则： 原始组件的代码无需修改，就可以被新的装饰器扩展。这意味着我的核心业务逻辑可以保持稳定，而新的功能则以装饰器的形式独立添加，这大大降低了引入新功能时对现有代码造成破坏的风险。
- 职责分离： 每个装饰器都专注于添加一个特定的功能，使得代码更模块化，职责更清晰。这在大型项目中，对于团队协作和代码的可读性都有很大的帮助。
我曾在一个项目中，需要为用户上传的图片添加多种处理功能，比如水印、缩略图、滤镜等。如果用继承，那简直是噩梦。后来引入装饰器模式，每个处理功能都是一个装饰器，用户可以根据需求自由组合，代码清晰且扩展性极强，那次经历让我对装饰器模式有了更深的理解和偏爱。
装饰器模式与继承、代理模式有何异同？何时选择装饰器？
在设计模式的学习中，装饰器、继承和代理这三者常常让人感到困惑，因为它们都涉及“包裹”或“扩展”现有对象。但它们的目的和应用场景其实大相径庭。
与继承的异同：
- 相同点： 表面上看，它们都能实现对原有功能的扩展。
-
不同点：
- 扩展时机： 继承是编译时的静态扩展，一旦子类定义好，其行为就固定了。装饰器是运行时的动态扩展，可以根据需要随时添加或移除功能。
- 扩展方式： 继承是“is-a”（是一种）的关系，子类是父类的一个特例。装饰器是“has-a”（有一个）的关系，装饰器“拥有”一个被装饰的对象，并为其添加额外行为。
- 灵活性： 继承是强耦合的，子类与父类紧密绑定，修改父类可能影响所有子类。装饰器是松耦合的，装饰器与被装饰对象通过接口协作，互不影响。
- 功能组合： 继承在功能组合多时会导致类爆炸。装饰器通过组合方式，可以灵活地堆叠功能，避免类爆炸。
在我看来，继承更适合于表示对象之间的层级关系和通用行为的抽取，当子类确实是父类的一种特殊类型时。而装饰器则更侧重于在不改变原有对象结构的前提下，为对象动态地增加新功能，尤其是在这些功能可以独立组合或分离时。
与代理模式的异同：
- 相同点： 两者都通过引入一个“包装器”对象来包裹另一个对象，并与被包裹对象实现相同的接口。
-
不同点：
- 目的： 代理模式的目的是控制对对象的访问，或者提供一个对象的替代品（例如，远程代理、虚拟代理、保护代理）。它通常不添加新的核心业务功能，而是管理对核心功能的访问。例如，一个权限代理会在调用实际方法前检查用户权限。
- 目的： 装饰器模式的目的是增强或添加对象的行为和职责。它是在不改变对象接口的前提下，为对象增加新的功能。例如，给咖啡加牛奶、加糖。
- 透明性： 装饰器模式通常要求对客户端透明，客户端在调用时不必关心它操作的是原始对象还是被装饰过的对象。代理模式有时也追求透明，但其核心是“替代”或“控制”。
何时选择装饰器？
我通常会在以下场景中倾向于使用装饰器模式：
- 需要动态地给对象添加或移除功能： 这是最直接的信号。如果你的功能是可插拔的，或者需要在运行时根据条件来决定是否添加，装饰器就是个好选择。
- 避免继承带来的类爆炸问题： 当你发现为了组合不同的功能而创建了大量子类时，是时候考虑装饰器了。
- 希望遵循开闭原则： 如果你希望在不修改现有类代码的情况下扩展其功能，装饰器模式能很好地帮助你实现这一点。
- 对象的职责需要分层或组合： 当一个对象的完整功能可以分解成多个独立的、可叠加的职责时，装饰器模式能让你的设计更加清晰。
举个例子，Java的I/O流就是装饰器模式的经典应用。
FileInputStream是基础组件，
BufferedInputStream、
DataInputStream等都是装饰器，它们在不改变
FileInputStream核心读写功能的前提下，提供了缓冲、数据类型读取等增强功能，并且可以层层嵌套。
实现装饰器模式时可能遇到的挑战和最佳实践？
虽然装饰器模式非常强大和灵活，但在实际应用中，我确实遇到过一些挑战，也总结了一些最佳实践。
可能遇到的挑战：
- 过度装饰导致复杂性增加： 当你过度使用装饰器，或者一个对象被太多层装饰器包裹时，整个对象图会变得非常复杂，难以理解和调试。想象一下，一杯咖啡被加了牛奶、糖、奶油、焦糖、巧克力酱，再加冰块，追踪每一层装饰器带来的影响会让人头大。
-
对象身份识别问题： 如果你的代码中需要比较对象的身份（例如使用
==
操作符或equals()
方法），被装饰的对象和装饰器本身是不同的实例。这可能导致一些预期之外的行为，特别是当你不小心将装饰器与原始对象混淆时。new MilkDecorator(new SimpleCoffee())
和new SimpleCoffee()
在Java层面是不同的对象。 - 初始化顺序和状态管理： 如果装饰器之间存在依赖关系，或者它们需要共享某些状态，那么初始化顺序和状态管理可能会变得复杂。例如，一个装饰器可能需要另一个装饰器提供的特定数据才能正确工作。
- 性能开销： 每次添加一个装饰器，都会引入一个新的对象实例和额外的间接调用。在对性能极度敏感的场景下，这可能带来微小的开销，虽然在大多数业务应用中这几乎可以忽略不计。
最佳实践：
-
保持装饰器的单一职责： 每个装饰器都应该只负责添加一个特定的、独立的功能。这不仅让装饰器本身更易于理解和维护，也避免了过度耦合。例如，
MilkDecorator
只管加牛奶，SugarDecorator
只管加糖。 - 确保装饰器正确委托： 所有的装饰器都应该在执行自己的逻辑之前或之后，调用被装饰对象的相应方法。这是装饰器模式能够正常工作的基石。忘记委托会导致功能缺失或错误。
-
考虑使用工厂或构建器模式来创建复杂的装饰链： 当装饰链很长或组合方式很多时，手动创建
new SugarDecorator(new MilkDecorator(new SimpleCoffee()))
这样的代码会变得冗长且难以阅读。可以引入一个工厂方法或构建器模式来封装装饰器的创建逻辑，提供更简洁的API。 - 清晰地文档化装饰器的行为： 尤其是在团队协作中，让其他开发者清楚每个装饰器的作用以及它们如何组合是至关重要的。在代码注释或设计文档中明确说明。
- 警惕循环引用： 虽然不常见，但理论上存在装饰器互相装饰导致循环引用的可能性。这会导致栈溢出或无限递归。
- 考虑使用Java 8的函数式接口或Lambda表达式： 对于一些简单的功能增强，有时候可以利用函数式接口和Lambda表达式来模拟装饰器的行为，减少类的创建，让代码更简洁。但这通常适用于行为比较简单，不需要太多状态的场景。
总的来说，装饰器模式是一个非常实用的设计模式，它提供了一种优雅的方式来扩展对象功能。但在使用时，保持清醒的头脑，不要过度设计，并遵循一些最佳实践，才能真正发挥其优势。
