Are all interface compositions considered as strategy pattern

user_4815218 0
Viewed 90

Using Strategy pattern, we can decouple behaviors using interfaces. Behaviors are moved in to interface which can have multiple implementations. Clients can have has-a-relationship to interface and can refer to any of its implementation in runtime.

In all explanations, it is mentioned as a solution to solve issues related to inheritance, where two classes in different branches in inheritance hierarchy need same behavior.

I think we can use the same approach to decouple behaviors from classes even when inheritance hierarchy is not present. A single class having a reference to interface can achieve multiple behaviors based on the implementation it is referring at runtime.

Can we call such use cases as an implementation of Strategy pattern? If so, are all has-a-relationships to interfaces considered as strategy pattern?

strategy-pattern design-patterns
2 Answers

In all explanations, it is mentioned as a solution to solve issues related to inheritance, where two classes in different branches in inheritance hierarchy need same behavior.

I've just read through most of the GoF book's description of Strategy, and I can't see that it mentions this aspect. That said, it seems a relevant enough concern.

If you reduce the Strategy pattern to its degenerate form, you have a Context that calls a method on its Strategy:

public Foo ContextInterface()
{
    return strategy.AlgorithmInterface();
}

As long as you have multiple (i.e. more than one) Strategy implementations, you could argue that it fits the pattern description.

As a general observation, some patterns in GoF are more specific than others. The Strategy pattern has always struck me as being so generic that it's in danger of being vacuous. It's close to being another name for polymorphism...

user_1260140

In the GoF book, every design pattern uses a consistent format, which includes intent, motivation, and applicability. The reasons for applying a pattern are critically important to the GoF, and the reasons may have nothing to do with syntax. In other words, applying the exact same syntax (e.g. a single composition relationship) for two different reasons may be two different patterns.

It is true of composition that,

...we can use the same approach to decouple behaviors from classes even when inheritance hierarchy is not present.

But from the GoF perspective, if the intent and motivation do not match, then the pattern may not match either.

I would refrain from referring to all composition relationships as Strategies because that dilutes the meaning of Strategy, confuses the meaning of composition, and destroys the common vocabulary which is arguably design patterns' greatest advantage.

I am in the habit of referring to the Strategy pattern as an OO solution for languages that lack first-class functions. I believe the pattern is more or less obsolete in modern OO languages, which all support closures or lambdas; however, I would not refer to all first-class functions as Strategies any more than I would refer to all composition that way.

user_13713290
Related