何时以及如何应用策略模式而不是装饰器模式?

发布于 2024-10-06 04:59:06 字数 282 浏览 0 评论 0原文

我正在学习设计模式并尝试遵循 Go4 书。在第 179 页,在装饰器模式章节中,有一行内容是

“..通过将策略的数量从一个扩展到一个 开放式列表,我们实现了与嵌套装饰器相同的效果 递归地。”

我不太明白这个说法。

侧重于拥有独立的算法,这些算法可以动态设置,并且不太了解它们所设置的客户端。

而装饰器并不完全独立于它们装饰的客户端。事实上,它们与它们所装饰的对象具有相同的超类型,

我在这里错过了一点吗?

I am learning design patterns and trying to follow Go4 book. On page:179, in the decorator pattern chapter, there is a line which says

"..by extending the number of strategies from just one to an
open-ended list, we achieve the same effect as nesting decorators
recursively."

I didn't quite get this statement.

Strategies focus on having independent algorithms, which can be set dynamically and don't know much about the client they are set in.

Whereas decorators are not quite independent of the clients they decorate. In fact, they are of same supertype as the object they decorate.

Am I missing a point here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

衣神在巴黎 2024-10-13 04:59:06

我将引用更多一些我认为有意义的上下文。

在 Component 类本质上是重量级的情况下,策略是更好的选择,从而使装饰器模式的应用成本太高。在策略模式中,组件将其某些行为转发到单独的策略对象。策略模式允许我们通过替换策略对象来更改或扩展组件的功能。

例如,我们可以通过让组件将边框绘制推迟到单独的 Border 对象来支持不同的边框样式。 Border 对象是一个封装了边框绘制策略的 Strategy 对象。通过将策略的数量从一个扩展到一个开放式列表,我们实现了与递归嵌套装饰器相同的效果。

这就是说,这两种模式都可以用来向基本组件添加行为,并且使用 Decorator 时,要添加多个行为,您可以嵌套装饰器,而使用 Strategy 时,您需要使用多种策略。

你是对的,策略通常比装饰器更独立于主要组件,但它们有可能了解组件。要使用策略模式,主要组件需要知道策略的存在,而装饰器不需要这样做。

I'll quote a little more of the context that I think is needed for this to make sense.

Strategies are a better choice in situations where the Component class is intrinsically heavyweight, thereby making the Decorator pattern too costly to apply. In the Strategy pattern, the component forwards some of its behavior to a separate strategy object. The Strategy pattern lets us alter or extend the component's functionality by replacing the strategy object.

For example, we can support different border styles by having the component defer border-drawing to a separate Border object. The Border object is a Strategy object that encapsulates a border-drawing strategy. By extending the number of strategies from just one to an open-ended list, we achieve the same effect as nesting decorators recursively.

All this is saying is that both patterns can be used to add behavior to your base component, and that with Decorator, to add multiple behaviors, you can nest the decorators, while with Strategy, you need to use multiple strategies.

You're right that strategies are generally more independent of the main component than decorators, but it is possible for them to be aware of the component. And to use the Strategy pattern, the main component is aware of the existence of strategies, where that's not needed with Decorator.

雨后彩虹 2024-10-13 04:59:06

要使用他们的示例,您可能有一个可以滚动和/或以各种方式绘制其边框(或根本不绘制)的窗口类。如果要使用继承来覆盖所有这些功能,则需要为每种可行的功能组合(无边框无滚动、有边框无滚动、无边框滚动、边框和滚动等)​​创建一个子类。当您添加更多功能时,这是一个不灵活的维护噩梦,因为类数量激增。

他们在这里提出的要点是,您可以使用策略模式或装饰器模式来更好地解决这个问题。您可以有一个 Window 类,它封装了滚动策略对象和边框策略对象。或者,您可以将 Window 对象包装在边框装饰器内,然后将其包装在滚动装饰器内。

但你的理解是完全正确的;这是两种不同的设计模式,具有不同的特征,从而导致不同的应用程序。使用装饰器,组件不知道正在添加功能的代理......因此您最终倾向于围绕现有组件类进行构建。对于策略,情况正好相反,因为组件正在使用(因此知道)代理来执行各种任务 - 这些代理通常不知道它们的管理组件。

To use their example, you might have a window class which can be scrolled and/or have its border painted in various ways (or not at all). If you were to use inheritance to cover all these features, you'd need one subclass for every feasible combination of features (no border no scrolling, border without scrolling, scrolling without border, border and scrolling etc.). This is an inflexible maintenance nightmare as you add more features because there's an explosion in the number of classes.

The main point they're making here is that you can use either the strategy pattern or the decorator pattern to better solve this problem. You could have a Window class which encapsulates a scrolling strategy object and a border strategy object. Or you could take your Window object, wrap it inside a border decorator and wrap that inside a scrolling decorator.

But you're completely right in your understanding; these are two different design patterns with different characteristics which lead to different applications. With Decorator, the Component has no knowledge of the agent which is adding functionality... and so you tend to end up building around an existing component class. With Strategy, it's the other way around since the Component is employing (and hence knows about) agents to perform various tasks - these agents generally don't know about their governing Components.

一梦浮鱼 2024-10-13 04:59:06

当您想对某件事使用多种方法时,请使用策略模式。当您想要创建某些东西可能会或可能不会用于更改对象/组件/任何内容时,那么您应该使用装饰器。换句话说,也可以说装饰器可能会添加功能(装饰)对象,而策略可能会交换功能。

when you want to use a multiple approaches to something, use a strategy pattern. When you want to create something where certain things may or may not be used to alter an object/component/whatever, then you should be using a decorator. in other words can also say a decorator is likely to add functionality (decorate) an object and a strategy is likely to swap functionality.

只等公子 2024-10-13 04:59:06

区别在于,在策略模式中,可以使用一个策略对象一次性向上下文提供信息。使用装饰器,您可以将策略堆叠在一起,从而获得他们所说的“开放式”数字。

The distinction is that in Strategy pattern, one Strategy object can be used to provide information to the Context at one time. With Decorator, you can stack Strategies on top of each other, and thus have what they refer to as "open-ended" numbers.

森林很绿却致人迷途 2024-10-13 04:59:06

当对象的身份对您很重要时,可以应用策略模式。无论应用多少策略,对象标识都保持不变,但对于装饰器模式
对象被封装在彼此内部,原始身份将在转换中丢失

  • 装饰模式改变对象的外表

  • 策略模式改变对象的内脏。

Strategy pattern can be applied when the identity of the Object is important to you. Object identity remains regardless of how many strategies are applied but for the Decorator pattern
Objects are encapsulated inside each other the original identity will be lost in the transformation

  • Decorator pattern changes the skin of an object

  • Strategy pattern changes the guts of an object.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文