使用列表而不是装饰器模式? [英] Using Lists Instead of Decorator Pattern?

问题描述

《 Head First:设计模式》一书中的Decorator Pattern用例使我有这个问题.我会试着写下来:

A Decorator Pattern use case from "Head First: Design Patterns" book made me have this question. I'll try to write it down:

这是一个咖啡店系统，里面有一些咖啡和许多调味品 您可以放入其中(需要支付额外费用)，您需要能够订购 并收取顾客想要的任何调味品的咖啡，以及 避免完全混乱(例如booleans保持追踪 调味品)使用装饰图案.我们有一个抽象的饮料 课，每种咖啡都作为具体成分和每种调味品 作为包装饮料的混凝土装饰工，如下所示:

It's a coffee shop system with some coffees and a lot of condiments you can put in them (for an extra cost), you need to be able to order and charge for a coffee with any condiments the costumer desires, and to avoid having total mayhem (e.g. booleans to keep track of the condiments) Decorator Pattern is used. We have an abstract Beverage class, each type of coffee as concrete components and each condiment as concrete decorators wrapping up a Beverage, like this:

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

And so we have the following process returning a coffee cost:

我的问题是:为什么不使用列表而不是装饰器来实现呢?我们可以在每种饮料中都有一个调味品清单，并通过遍历清单来计算成本.要订购咖啡，我们只需要实例化一次并添加所需的调味品，就可以避免像这样的声明:

My question is: Why not implement this with Lists instead of the Decorator? We could have a list of Condiment in each Beverage and calculate the cost by iterating through the List. To order a coffee we would just have to instantiate it once and add the desired condiments, avoiding declarations like:

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

此外，一旦没有装饰工来包装咖啡，我们将在操作上有更大的灵活性，例如为咖啡打折(不包括调味品).这是一个经过长期研究的问题，我知道我遗漏了一些东西，或者我弄错了一些东西，因此，如果您对此有任何想法，我希望进一步了解和讨论.

In addition to that we would have more flexibility for operations like giving discount for a coffee not including it's condiments, once we won't have decorators wrapping up the coffee. This is a matter that have been long studied, I know I'm missing something or maybe I got something wrong, so if you have any thoughts on this I would love to know and discuss it further.

推荐答案

Decorator模式是关于在运行时装饰(增强)具有附加功能的对象.

Decorator pattern is about decorating ( enhancing ) an object with additional features at runtime.

假设您已经有一个类，可以将其称为实现接口IA的类A.现在，如果需要添加其他功能，我们希望它具有方法someAlignFeatureToA()，而A中没有该方法.现在，您可以选择扩展类A.另一种方法是Composition，它应优于Inheritance.您可以将类A的对象包装在另一个类B中，该类实现与A相同的Interface，即IA.这样，对于客户端代码，将很容易接受类B的对象，因为它具有与类A相同的接口.(假设代码编写得很好，取决于抽象(接口IA)，而不是具体的.诸如A类的类).

Suppose you already have a class, lets call it class A which implements an interface IA. Now if there is a requirement of adding an additional feature for which we want it to have a method ,someAlignFeatureToA() which was not there in A. Now you have an option of extending the class A. Another approach is Composition which should be favoured over Inheritance. You can wrap the object of class A in another class B implwmenting the same Interface as of A i.e. IA. This way for the client code it would be easy to accept the object of class B as it has the same interface as of A. (Assumption is the code is well written which depends on the Abstractions (interface IA) and not on concrete classes like class A).

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

This way the inheritance chain is not too long and you can add additional features at runtime easily.

现在回答您的问题:是的，在您提出问题的示例中，列表更合适，但我觉得作者打算用一个简单的示例来解释Decorator模式的用法. 假设咖啡由牛奶，咖啡混合粉和糖制成.咖啡粉还由较小的成分组成.这里出现的解决方案类似于Composite模式.

Now coming to your question : Yes in the example you took in your question, a List fits better, but I feel its the intention of the author to explain usuage of Decorator pattern with an easy example. Suppose Coffee is made up of milk, coffee mix and sugar. Coffee mix is further made up of smaller components . Here the solution emerges similar to Composite pattern.

装饰器模式是基于行为增强的设计模式. Java IO流在装饰类增强行为(方法实现)的情况下使用此方法(一个流与另一个流包装在一起以增强前一个流)

Decorator pattern is design pattern based on Enhancement of Behavior. Java IO streams uses this where behavior (method implementation) is enhanced by the decorating class (one stream is wrapped with another to enhance thr previous one)

这篇关于使用列表而不是装饰器模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！