The next time I see a Strategy class in a language that supports lambdas it'll become a Gang of Two.

Hm, why?

Which is easier to test?

@MammaNeedHummus If a strategy is large enough to warrant a unit test, it should be a function called from a lambda. Classes are for encapsulating state, not for picking a function. Problems should be preferably solved with the simplest tool that is future proof, so that code is easier to reason about.

I am confused how can you replace strategy pattern with lambdas? Idea of it is avoid code duplication and support open closed principle. Lambda does not support open principle. Strategy encapsulates similar behaviours with different implementations.

@rim01 A strategy class does not contain mutable state. It doesn't necessarily have to be replaced by a lambda, often it can be replaced by a function called in a lambda. By the way, I don't generally see extensions of strategies, have you seen a real-world example of this? My experience is that they're generally composed into bigger structures without any sort of reuse of the original strategy's identity, and their primary effect is inseparably tying arbitrary solution-domain classifications to very universal problem-domain attributes of the objects that could otherwise fit into any strategy bounded only by the (often single) function's return type

I used it for different caching implementations, nosql data storage where data is separated per classes as well as working with 2 different databases 1 for writing and second just for reading. It has use cases if it is used correctly if not it just confuses developers and does not help. I am thinking that if you able to replace strategy pattern with lambda function that mean it was no use of it within that software. The goal of patterns is to minimise duplication and apply only when it is needed. I usually invest in it when it is more than 2 cases of duplication.