When and How Strategy pattern can be applied instead of decorator pattern?

Question

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?

Answer 1

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.

Answer 2

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.