Strategy pattern misrepresented to be the client of a strategy
dhulke opened this issue · 2 comments
The explanation starts off well, comparing the strategy design pattern to function pointers in structured programming, interfaces in OO and higher order functions in FP, but it derailed by shifting attention to the client of a strategy and ultimately comparing it to functors and concluding: "namely the injecting of a function into a computational context and its execution in this context".
As stated in GoF under the Strategy Design Pattern:
"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."
Attention to "encapsulates" and "lets the algorithm vary independently from clients that use it". By "use it" we should understand to make a call or to execute such algorithm. A few sections down we read:
"We can avoid these problems by defining classes that encapsulate different linebreaking algorithms. An algorithm that's encapsulated in this way is called a strategy."
Notice that the definition of the strategy pattern is independant of the "computational context and its execution in this context" as this is more of a way to model the aplication than to execute the modeled aplication.
The explanation also misrepresents the strategy pattern in Java by creating multiple interfaces when the pattern clearly defines only one interface for the many "strategies" of computation that will be selected and eventually injected by another pattern, into a context of execution. The very notion of the Strategy Design Pattern could be said to be averse to composition and this example does the exact opposite.
I suggest looking into Composite, Proxy and Decorator design patterns as good options of "injecting of a function into a computational context and its execution in this context".
You are right.
I‘ll try to find a better match for functor and will also try to find cover the strategy pattern in a better way.