本文是小编为大家收集整理的关于关于装饰器模式和抽象装饰器类的问题？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
已经这里提出了这个问题，但不是回答具体问题，而是描述而是给出了装饰器模式的工作原理.我想再问一次，因为仅仅通过阅读装饰器模式的工作原理对我来说答案并没有立即显现出来(我已经阅读了维基百科的文章和《Head First Design Patterns》一书中的部分).
基本上，我想知道为什么必须创建一个抽象装饰器类来实现(或扩展)某些接口(或抽象类).为什么所有新的"装饰类"都不能简单地实现(或扩展)基本抽象对象本身(而不是扩展抽象装饰器类)?
为了更具体，我将使用设计模式书中处理咖啡饮料的示例:
- 有一个抽象组件类叫Beverage
- 简单的饮料类型，例如 HouseBlend 只需扩展 Beverage
- 为了装饰饮料，创建了一个抽象的 CondimentDecorator 类，它扩展了 Beverage 并有一个 Beverage 的实例
- 假设我们要添加"牛奶"调味品，创建了一个扩展 CondimentDecorator 的类 Milk
我想了解为什么我们需要 CondimentDecorator 类以及为什么类 Milk 不能简单地扩展 Beverage 类本身并在其构造函数中传递一个 Beverage 的实例.
希望这很清楚......如果不是我只是想知道为什么这个模式需要抽象装饰器类?谢谢.
编辑:我尝试实现这一点，省略了抽象装饰器类，它似乎仍然有效.这个抽象类出现在这个模式的所有描述中，仅仅是因为它为所有新的装饰类提供了一个标准接口吗?
推荐答案
它可以使用不同组合的各种装饰器独立地装饰基类，而不必为每个可能的组合派生一个类.例如，假设您希望 Beverage 带有牛奶和肉豆蔻.使用基于抽象装饰器类的装饰器，您只需使用 Milk 和 Nutmeg 装饰器进行包装.如果它是从 Beverage 派生的，则必须有一个 MilkWithNutmegBeverage 类和一个 MilkBeverage 类和一个 NutmegBeverage 类.您可以想象随着可能组合数量的增加，这种情况会如何爆炸.使用抽象装饰器实现可以将其减少到每个装饰只有一个装饰器类实现.
问题描述
This question was asked already here, but rather than answering the specific question, descriptions of how the decorator pattern works were given instead. I'd like to ask it again because the answer is not immediately evident to me just by reading how the decorator pattern works (I've read the wikipedia article and the section in the book Head First Design Patterns).
Basically, I want to know why an abstract decorator class must be created which implements (or extends) some interface (or abstract class). Why can't all the new "decorated classes" simply implement (or extend) the base abstract object themselves (instead of extending the abstract decorator class)?
To make this more concrete I'll use the example from the design patterns book dealing with coffee beverages:
- There is an abstract component class called Beverage
- Simple beverage types such as HouseBlend simply extend Beverage
- To decorate beverage, an abstract CondimentDecorator class is created which extends Beverage and has an instance of Beverage
- Say we want to add a "milk" condiment, a class Milk is created which extends CondimentDecorator
I'd like to understand why we needed the CondimentDecorator class and why the class Milk couldn't have simply extended the Beverage class itself and been passed an instance of Beverage in its constructor.
Hopefully this is clear...if not I'd simply like to know why is the abstract decorator class necessary for this pattern? Thanks.
Edit: I tried to implement this, omitting the abstract decorator class, and it seems to still work. Is this abstract class present in all descriptions of this pattern simply because it provides a standard interface for all of the new decorated classes?
推荐答案
It enables the decoration of the base class independently with various decorators in different combinations without having to derive a class for each possible combination. For example, say you want your Beverage with milk and nutmeg. Using decorators based on the abstract decorator class, you merely wrap with with Milk and Nutmeg decorators. If it was derived from Beverage, you'd have to have a MilkWithNutmegBeverage class and a MilkBeverage class and a NutmegBeverage class. You can imagine how this explodes as the number of possible combinations increases. Using the abstract decorator implementation reduces this to just one decorator class implementation per decoration.
更多相关问答
联系站长