When and How Strategy pattern can be applied instead of decorator pattern?_问答_开发者

I am learning design patterns and trying to follow Go4 book. On page:17开发者_开发技巧9, 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?

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.

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.

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.

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.

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