使用列表而不是装饰模式？
来自“头先：设计模式”书的装饰模式用例让我有这个问题。 我会尽力写下来：
这是一个咖啡店系统，有一些咖啡和很多可以放在里面的调味品（需要支付额外费用），你需要能够根据客户需要的任何调味品订购咖啡并收取费用， （例如布尔值来追踪调味品）使用Decorator Pattern。 我们有一个抽象的饮料类，每种类型的咖啡都是混凝土组分，每种调味品都是作为具体装饰者包装一种饮料的，如下所示：
所以我们有以下流程返回咖啡成本：
我的问题是：为什么不用装饰器而是用List来实现呢？ 我们可以在每个饮料中列出调味品列表，并通过遍历列表来计算成本。 要订购一杯咖啡，我们只需将其实例化一次并添加所需的调味品，避免如下所示的声明：
// Using second image example
Beverage beverage = new DarkRoast(beverage);
beverage = new Mocha(beverage);
beverage = new Whip(beverage);
除此之外，我们还可以有更多的灵活性，例如给咖啡提供折扣（不包括调味品），一旦我们不会让装饰者包装咖啡。 这是一个长期研究的问题，我知道我错过了一些东西，或者我错了，所以如果你对此有任何想法，我很想知道并进一步讨论它。
你应该区分数据和行为。
装饰器是一个间接处理一个非常具体问题的层。 数据（根据类型，合同，协议等）保持不变，但您在实施方面获得更多灵活性。 使用装饰器，您可以重新使用现有功能并开始添加更改 - 与适配器配合使用后，您可以慢慢地从pone API迁移到其他适配器并保持兼容。
列表只应负责以特定方式提供对所包含数据的访问权限。 对数据执行任务/处理列表中包含的数据应该由具有不同职责的函数/对象/类完成。
你所讲的是一种计算饮料总成本的方法。 更笼统地说，您提出了一种替代方法来合并和执行Decorator模式假设的每个派生对象的主要行为，方法是将它们合并到一个列表中。 这也不是一个面向对象的方法。
但装饰者模式的原始意图去更广泛的视角，除此之外。 它正在动态地将扩展功能添加到对象 。 这意味着我有一些对象O1 ＆我想要它将其转换为另一个具有扩展功能的对象O2 ，但仍然是可以互换的。
所以这是关于如何根据对象生命周期来管理对象进化 。 希望你明白了。 :)）
Decorator模式是关于在运行时使用附加功能装饰（增强）对象。
假设你已经有了一个类，我们称之为类A ，它实现了一个接口IA 。 现在，如果需要添加一个我们希望它有一个方法的附加功能，那么在A中就不存在someAlignFeatureToA() 。 现在您可以选择扩展A类。 另一种方法是Composition ，应该比Inheritance更受青睐。 您可以将A类的对象包装到另一个B类中，从而实现与A即IA相同的Interface 。 这种方式对于客户端代码来说很容易接受B类的对象，因为它具有与A相同的接口。（假设代码写得很好，取决于Abstractions（接口IA ），而不是具体的类A类）。
通过这种方式，继承链不会太长，您可以轻松地在runtimw中添加其他功能。
链接地址: http://www.djcxy.com/p/39135.html