使用列表而不是装饰模式？

Question

"Head First:Design Patterns"一书中的Decorator Pattern用例让我有了这个问题.我会试着写下来:

这是一个咖啡店系统,有一些咖啡和许多调味品可以放入其中(需要额外付费),你需要能够订购和收取客户所需的任何调味品的咖啡,并避免完全混乱(例如,用于跟踪调味品的布尔值)使用装饰器图案.我们有一个抽象的Beverage类,每种类型的咖啡作为混凝土组件,每种调味品都作为包装Beverage的混凝土装饰器,如下所示:

所以我们有以下过程返回咖啡费用:

我的问题是:为什么不用列表而不是装饰器来实现它？我们可以在每个饮料中有一份调味品清单,并通过迭代列表来计算成本.要订购咖啡,我们只需要实例化一次并添加所需的调味品,避免声明如下:

// Using second image example
Beverage beverage = new DarkRoast(beverage);
beverage = new Mocha(beverage);
beverage = new Whip(beverage);

除此之外,我们将有更多的灵活性来进行操作,比如给咖啡打折,不包括它的调味品,一旦我们没有装饰员包装咖啡.这是一个长期研究过的问题,我知道我错过了一些东西或者说我错了,所以如果你对此有任何想法,我很想知道并进一步讨论.

Answer 1

Decorator 模式是关于在运行时装饰（增强）具有附加功能的对象。

假设你已经有一个类，让我们称它为A实现接口的类IA。现在，如果需要添加附加功能，我们希望它有一个方法，someAlignFeatureToA()而A. 现在您可以选择扩展类A。另一种方法是Composition应该被青睐的Inheritance。你可以用类的对象A在另一个类Bimplwmenting同Interface为A即IA。这种方式对于客户端代码，很容易接受类 B 的对象，因为它具有与 A 相同的接口。（假设代码写得很好，它依赖于抽象（接口IA）而不是像类这样的具体类A）。

这样继承链不会太长，您可以在运行时轻松添加其他功能。

现在来回答你的问题：是的，在你提出的问题的例子中，列表更适合，但我觉得作者的意图是用一个简单的例子来解释装饰模式的用法。假设咖啡是由牛奶、咖啡混合物和糖组成的。咖啡混合物进一步由较小的成分组成。这里的解决方案类似于复合模式。

装饰者模式是基于行为增强的设计模式。Java IO 流使用它，其中行为（方法实现）由装饰类增强（一个流被另一个流包裹以增强前一个流）