装饰器模式:为什么需要抽象装饰器? [英] Decorator pattern: Why do we need an abstract decorator?

查看:517
本文介绍了装饰器模式:为什么需要抽象装饰器?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

已经在此处询问了此问题,但没有回答具体问题,而是而是给出了装饰器模式的工作方式.我想再问一遍,因为答案并不能立即显示出装饰器模式的工作原理(我已经阅读了维基百科的文章和《 Head First Design Patterns》一书中的章节).

基本上,我想知道为什么必须创建一个抽象装饰器类来实现(或扩展)某些接口(或抽象类).为什么所有新的装饰类"都不能简单地实现(或扩展)基本抽象对象本身(而不是扩展抽象装饰器类)?

为了更具体一点,我将使用设计模式书中涉及咖啡饮料的示例:

  • 有一个名为Beverage
  • 的抽象组件类.
  • 诸如HouseBlend的简单饮料类型仅扩展了Beverage
  • 要装饰饮料,将创建一个扩展Beverage并具有Beverage
  • 实例的抽象CondimentDecorator类.
  • 假设我们要添加牛奶"调味品,将创建扩展CondimentDecorator
  • 的类Milk

我想了解为什么我们需要CondimentDecorator类,以及为什么Milk类不能简单地扩展Beverage类本身并在其构造函数中传递Beverage的实例. /p>

希望这很清楚... 如果不是,我只是想知道为什么这种模式需要抽象装饰器类?谢谢.

我试图实现这一点,省略了抽象装饰器类,并且它似乎仍然可以工作.该抽象类是否存在于此模式的所有描述中,仅仅是因为它为所有新修饰的类提供了标准接口?

解决方案

它可以使用各种装饰器以不同的组合独立地对基类进行装饰,而不必为每种可能的组合派生一个类.例如,假设您要Beverage搭配牛奶和肉豆蔻.使用基于抽象装饰器类的装饰器,您只需使用MilkNutmeg装饰器进行包装.如果它是从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.

这篇关于装饰器模式:为什么需要抽象装饰器?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆