HeadFirst书中的装饰器模式示例与将对象存储在容器中

Question

我正在阅读Head First Design Patterns中的Decorator模式，并且在互联网上也通过一些与之相关的例子。

我怀疑它的相关性。

假设书中的咖啡类示例，我们有咖啡装饰（或包装）咖啡类的调味品，并调用getCost（）函数，这反过来将从咖啡类调用getCost（）函数。

相反，我更愿意让我的咖啡类将调味品对象存储在矢量中，并通过调用该矢量中所有调味品的getCost（）方法来计算总成本。

我在这里缺少什么，这个设计有漏洞吗？

感谢。

Answer 1

我发现这里的描述https://en.wikipedia.org/wiki/Decorator_pattern有助于掌握模式的基础知识。我建议仔细阅读，但我收集的一些内容可能会给你基本答案：

1. 在某些情况下，您需要从类树中的对象上获取功能，而不需要在每个对象上使用它，并且将该功能添加到基类中以用于一组狭窄的案例会导致代码膨胀，同时将其添加到多个（但并非所有需要该功能的子类都会导致代码重复成为配置管理的头痛问题。
2. 有些情况下，您无法控制正在使用的类的结构，也无法像您在问题中所建议的那样直接扩展它们。
3. 在您希望能够添加到对象的多个可选行为的情况下，执行子类继承变得越来越困难，因为您必须为所有选项组合创建子类。