On: On Design Patterns in C++

[ptr]

This is the crux of the matter. Design patterns are just common structures that have been found useful at some point in some context. Some programming languages have adopted these patterns, adding "native" support for them. If your programming language didn't have parameters, then yes, I guess someone would add the "Parameter Pattern". It's all rather arbitrary what ends up in a book on "design patterns".

Regarding the strategy pattern, when does it start becoming the pattern and when is it just "passing a function as a parameter"?

   sortList(list, [](const item& i) {return i.name();});

   struct MySorter
   {
      bool operator ()(const item&) {...}
   };

   sortList(list, MySorter{});

   class MySorter : public ISorter
   {
   public:
      virtual bool execute(const item&) override {...}
   };

   sortList(list, MySorter{});

[thom → ptr]

Design patterns aren't common _structures_. I suppose this is why everyone gets so caught up in the language specifics and think they're trivial. Design patterns are common _design decisions_. The strategy pattern isn't saying "you can have callbacks", it's saying "sometimes you should allow a policy to be supplied by the user". Every day, in every language, even the ones with first class functions and people posting on the internet that design patterns aren't needed, people still use libraries with massive 'options' arguments to functions, instead of internalising the actual lesson of the strategy pattern which is to allow executable specifications of behaviour.

So yes, there are trivial things which you can argue the toss on, but in the last month I've used HTTP libraries that don't allow you to supply a strategy for retry logic and machine learning libraries that don't allow a strategy for early stopping.