从CRP到装饰器模式：动态组合的艺术
大家好，我是你们的老朋友。今天我们来聊聊一个很有意思的话题——从组合复用原则（CRP）到装饰器模式。说实话，我在刚入行那会儿，对这两个概念的理解也是模棱两可的。直到有一次，我在一个图形编辑器项目中，被需求变更折磨得够呛，才真正体会到它们的价值。
组合复用原则：继承的替代方案
先说说组合复用原则。这个原则的核心思想很简单：优先使用对象组合，而不是类继承。为什么？你想想看，继承是一种静态关系，编译时就确定了。而组合是动态的，运行时可以灵活调整。
核心区别：
- 继承：白箱复用，父类实现细节对子类可见
- 组合：黑箱复用，通过接口交互，内部实现隐藏
我在项目中遇到过这样一个场景：我们需要为不同的UI控件添加滚动功能。如果用继承，就得为每个控件创建一个带滚动的子类。但用组合呢？直接写一个ScrollDecorator，把控件包进去就行了。代码量少了一半，维护起来也轻松多了。
装饰器模式：动态组合的典范
装饰器模式，说白了就是组合复用原则的一个具体实现。它允许你动态地给对象添加新功能，而不改变其结构。
嗯，这里要注意：装饰器和继承都能扩展功能，但方式完全不同。继承是在编译期静态扩展，装饰器是在运行期动态扩展。我个人习惯用一句话来区分：继承是"我是谁"，装饰器是"我有什么"。
一个简单的例子
假设我们有一个咖啡系统。基础咖啡有美式、拿铁等。顾客可以加糖、加奶、加奶油。如果用继承来实现：
// 继承方式——类爆炸
class Coffee { /* ... */ };
class CoffeeWithSugar : public Coffee { /* ... */ };
class CoffeeWithMilk : public Coffee { /* ... */ };
class CoffeeWithSugarAndMilk : public Coffee { /* ... */ };
// 每多一种配料，类数量翻倍！你看，这很快就失控了。3种配料就需要8个类。那用装饰器呢？
// 装饰器方式——优雅组合
class Coffee {
public:
virtual double cost() = 0;
virtual string description() = 0;
};
class Decorator : public Coffee {
protected:
Coffee* coffee;
public:
Decorator(Coffee* c) : coffee(c) {}
};
class SugarDecorator : public Decorator {
public:
SugarDecorator(Coffee* c) : Decorator(c) {}
double cost() override { return coffee->cost() + 0.5; }
string description() override {
return coffee->description() + " + sugar";
}
};
// 使用
Coffee* myCoffee = new SugarDecorator(
new MilkDecorator(
new AmericanCoffee()
)
);看到了吗？装饰器模式把"添加功能"这件事，变成了层层包裹的过程。每个装饰器只负责一件事，组合起来就能产生无限可能。
装饰器 vs 继承：一张图看懂
为了让你更直观地理解两者的区别，我画了一张对比图：
什么时候用装饰器？
根据我的经验，装饰器模式特别适合以下场景：
- 功能组合不确定：你不知道用户会怎么组合功能，装饰器让你"兵来将挡"
- 避免类爆炸：就像上面的咖啡例子，用继承会生成大量子类
- 功能需要动态增减：运行时决定要不要加某个功能
小提示：装饰器模式虽然灵活，但也不是万能的。如果功能组合是固定的，或者你只需要一两种变体，直接用继承反而更简单。别为了用模式而用模式。
避坑指南
我曾经踩过的坑：
- 装饰器链过长：有一次我嵌套了7层装饰器，调试时根本分不清哪个装饰器出了问题。建议装饰器嵌套不超过3-4层。
- 类型信息丢失：装饰器返回的是抽象组件类型，如果你需要访问具体类型的方法，装饰器就不太合适了。
- 性能开销：每个装饰器都增加了一层间接调用。在性能敏感的场景，比如游戏引擎的渲染管线，要谨慎使用。
总结
装饰器模式是组合复用原则的完美体现。它用动态组合替代了静态继承，让代码更灵活、更易扩展。我个人觉得，掌握装饰器模式的关键，就是理解"包装"这个概念——每个装饰器都是一层包装，层层叠加，功能自然丰富起来。
记住：继承是"是什么"，组合是"有什么"。当你下次遇到需要给对象动态添加功能的需求时，不妨想想装饰器模式。它可能不是唯一的解决方案，但往往是最优雅的那个。