gpt4 book ai didi

java - 装饰器模式 : Why do we need an abstract decorator?

转载 作者:IT老高 更新时间:2023-10-28 21:07:25 25 4
gpt4 key购买 nike

这个问题已经被问过了 here ,但不是回答具体问题,而是给出了装饰器模式如何工作的描述。我想再问一次,因为仅仅通过阅读装饰器模式的工作原理对我来说答案并没有立即显现出来(我已经阅读了维基百科的文章和《Head First Design Patterns》一书中的部分)。

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

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

  • 有一个抽象的组件类叫Beverage
  • HouseBlend 等简单饮料类型只需扩展 Beverage
  • 为了装饰饮料,创建了一个抽象的 CondimentDecorator 类,它扩展了 Beverage 并具有 Beverage
  • 的实例
  • 假设我们要添加“牛奶”调味品,则创建一个扩展 CondimentDecorator
  • 的类 Milk

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

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

编辑:我尝试实现这一点,省略了抽象装饰器类,它似乎仍然有效。这个抽象类出现在这个模式的所有描述中,仅仅是因为它为所有新的装饰类提供了一个标准接口(interface)吗?

最佳答案

迟到一年半总比没有好:

不需要特定接口(interface)的装饰器的基类。

但是,拥有以下内容非常有用:

  • 一方面,作为一种记录从它派生的类是相关接口(interface)的装饰器的方法

  • 但主要是因为装饰器通常不需要为被装饰接口(interface)的每个方法添加功能。

因此,基装饰器类允许派生装饰器仅实现它们实际需要添加某些功能的接口(interface)的那些方法,而将其余方法留给基类以提供默认实现。 (这只是将调用委托(delegate)给受邀者。)

与编写从头开始实现装饰接口(interface)的装饰器相比,编译器要求您为接口(interface)的每个方法提供一个实现,无论您的装饰器是否会为其添加任何功能。

就是这么简单,真的。

关于java - 装饰器模式 : Why do we need an abstract decorator?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2016765/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com