Return to Answer

This is a form of polymorphism. You can compare it to subtype polymorphism of the kind offered by OOP languages that support class inheritance. Those languages usually resorts to single dispatch, at runtime, to choose an implementation to satisfy a virtual call. Single dispatch in this case is based on the type of the object at runtime (a single value). Multiple dispatch can choose which way to go based on multiple values. You have a function type, multiple implementations and we polymorphically choose one at runtime based on one of multiple values, hence multiple dispatch.

This is a form of polymorphism. You can compare it to subtype polymorphism of the kind offered by OOP languages that support class inheritance. Those languages usually resorts to single dispatch, at runtime, to choose an implementation to satisfy a virtual call. Single dispatch in this case is based on the type of the object at runtime (a single value). Multiple dispatch can choose which way to go based on multiple values. You have a function type, multiple implementations and we polymorphically choose one at runtime based on one of multiple acceptable values, hence multiple dispatch.

In languages that support multi-methods (e.g. Clojure), this is not a problem at all because the language itself can express this relationship between a specific value and a function that needs to be called for it.

This is a form of polymorphism. You can compare it to subtype polymorphism of the kind offered by OOP languages that support class inheritance. Those languages usually resorts to single dispatch, at runtime, to choose an implementation to satisfy a virtual call. Single dispatch in this case is based on the type of the object at runtime (a single value). Multiple dispatch can choose which way to go based on multiple values. You have a function type, multiple implementations and we polymorphically choose one at runtime based on one of multiple values, hence multiple dispatch.

In languages that support multi-methods (e.g. Clojure), this is not a problem at all because the language itself can express this relationship between a specific value and a function that needs to be called for it.

Others answers already discuss it, so I will try to contribute new angles to the analysis.

My take is that your code can only be a strategy pattern if the algorithm is dynamically chosen, i.e. strategy calls cannot be statically defined in code. My example of a table with multiple dispatch support might be considered a strategy, or passing a strategy function to the service layer for it to call eventually would also be OK.

In a languages that support functions as first-class citizens, the so called strategy pattern is just a regular function that encapsulates an algorithm. In OOP languages the function is encapsulated in an object (called strategy) that you use to reach the function inside it (that’s the case of e.g. Java).

Additionally, you can probably see how powerful it is that the three algorithms operate on the same data structure, instead of having different data structures for every algorithm. This allows the definition of a single “function signature”, a “public interface” that you can use to exploit the pattern of polymorphism i.e. Implement three different functions who's type is the same, but behave completely different. That’s how I could defined a functional dispatch using a map in my example above.

Other answers already discuss it, so I will try to contribute new angles to the analysis.

My take is that your code can only be a strategy pattern if the algorithm is dynamically chosen, i.e. strategy calls cannot be statically defined in code. Additionally, the strategy must be passed to a context that will use it to provide a service operation to a client.

strategy = dispatch[algorithmType] context(strategy) context.operation() 

Alternatively, I would still accept context.operation(strategy). However, I know opinions might differ on what constitutes a valid strategy pattern.

Anyways, you can probably see that in languages that support functions as first-class citizens, the so-called strategy pattern is just a regular function that encapsulates an algorithm. In OOP languages the function is encapsulated in an object (called a strategy) that you use to reach the function inside it (that’s the case of e.g. Java).

Additionally, you can probably see how powerful it is that the three algorithms operate on the same data structure, instead of having different data structures for every algorithm. This allows the definition of a single “function signature”, a “public interface” that you can use to exploit the pattern of polymorphism i.e. Implement three different functions whose type is the same, but behave completely different. That’s how I could define a functional dispatch using a map in my example above.