Is the “Strategy” design pattern part of other patterns?

Question

Recently, I find myself thinking that the “Strategy” design pattern is a common manifestation of polymorphism and is used in many other patterns. Let me remind the "Strategy" chart:

And now about exactly what patterns the “Strategy” is used in.

Abstract factory. In fact, the hierarchy of factories is a strategy, the client uses one or another factory method depending on the situation.

Bridge. An implementation hierarchy can be a combination of a base class and two or more derived classes that implement a single operation in different ways:

Moreover, a strategy can be found in templates such as Mediator (if there is a hierarchy of classes whose objects interact with each other), Proxy, Prototype, and others.

The question is, how correct is such an interpretation that the “Strategy” is a class hierarchy with redefinition of any algorithm? After all, if this interpretation is correct, then about half of the GOF-patterns may include a “Strategy”. And, by the way, some of them (for example, the same "Bridge") use one or another algorithm depending on the context.

Simply using this polymorphism for its own purposes where possible.
The client chooses the factory method, but some other part of the program can set the strategy, and, generally speaking, nothing depends on the client.
@Sergey And the factory method may not be chosen by the client, and the strategy may be chosen by the client.
In the mediator, I spoke about the case when there are several interacting classes that implement a common interface, and the mediator chooses a strategy (with whom to interact)
And the mediator also serves a specific task - to be a mediator between this and that.
The strategy is to choose an algorithm for an arbitrary task.
One strategy is print мяу-мяу , another print гав-гав .
Do not return any object, do not represent any third object.
To implement the factory, the mediator and there is little else that can be applied strategy, with appropriate algorithms, if necessary.

Answer 1 · 2016-11-19T12:51:01

I can not give an exact answer to your question, but I can push to the expected answer.

In the “Strategy” design pattern , it is based on the method of adding and replacing objects during program execution. Perhaps the minimal example. The strategy best illustrates this principle and therefore you can see its reflection in other templates. But in fact, this architectural solution has a lower-level abstract definition and is called "Aggregation" .

Surely everyone is familiar with the "Composition" , this is when an object inside itself creates the objects it needs. So "Aggregation" is when an object gets its dependencies from the outside world. And this principle is one of the pillars of decent programming. After all, the same gang of four in his book says that composition is preferable to inheritance. But there is also an expression that aggregation is preferable to composition.

Perhaps the understanding that the "Strategy" describes the lower-level principles of programming and is the reason that it is everywhere?

I think that this is indeed a more “low-level” pattern, like the Facade, for example, which can also be seen in most patterns.
The fact is that the Facade is the implementation of the principle of concealment.
That is, there is a principle-law of programming, and the implementation is the embodiment of this law in the code, this is the Facade.
The same with the Strategy, it is the implementation of the principle of aggregation.
Generally speaking, there may not even be some predefined class initially.
And the fact that something will be replaced there is a side effect.

Is the “Strategy” design pattern part of other patterns?

1 answer 1

More articles: