I'm not sure I agree with the author of this book that that counts as an example of "The Strategy Pattern" (vs. simply "passing a function as a parameter").

Is having parameters at all "The Parameter Pattern"? Should we call passing a boolean flag "The Flag Pattern"?

To me, "Design Pattern" implies at least some higher order structure than that (and which is not natively abstractable over in the language in question).

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{});

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.

>Is having parameters at all "The Parameter Pattern"?

Yes

> Should we call passing a boolean flag "The Flag Pattern"?

The fact that we call it a flag, in itself a metaphor, shows that this is exactly what is happening already. We just omit the "pattern" as it is not necessary for understanding.

Pattern just means "something that occurs repeatingly". Some things do so obviously, others a bit less obviously.

My experience teaching comp. sci. is that when faced with problems that call for design patterns, ~40% of 20/22 y.o. students are able to come up with the "classical" design pattern implementations on their own in a couple hours without prior exposure to them. For the rest, well, we have the books.

> students are able to come up with the "classical" design pattern implementations on their own in a couple hours without prior exposure to them.

I think this is even mentioned in the GoF book. The point of naming these patterns is not that they're amazingly innovative. The point of "Patterns" is that when we give them a name we can (a) discuss them easier with a common language, and (b), we can recognise when we use them again so to remember the pitfalls of last time.

Yeah, pretty much. All languages have design patterns, but somehow everything in Java becomes a Pattern. So whether something is called a pattern or not is definitely very culture-dependent.

I think this about monads in Haskell. They're a design pattern (well, several different patterns). They just aren't called that.

Design patterns are considered to be things that you can’t express directly in the language (that’s the Design Patterns book definition). Monads can definitely be expressed directly in Haskell. The only thing you can’t do is prove the Monad laws in Haskell (I think?).

Other languages, like e.g. Rust (because of lack of HKT), cannot express monads like Haskell can.

But yeah, you can definitely call it a design pattern if that’s what the culture around the language is like. But it would be like Java folks calling interfaces with default implementations for something goofy like “Interface with stateless implementations pattern”, and even they don’t go that far.

Late reply; I didn't see this earlier.

But in Haskell, a lot of the time you don't use a monad because you want a monad. You use a monad to do something else - to log in a pure way, for example. That use of a monad to solve a particular problem is a pattern.

I'd even argue that it's using the pattern to compensate for a weakness of the language. (Or, if you prefer, to help with things that are difficult within the language design and philosophy.)

That's sometimes called language idiosyncrasies.

>>Should we call passing a boolean flag "The Flag Pattern"?

You mean like a bit field?

Did you realized that with only two words you can convey amultitude of information regarding it's use and implementation and properties?

Two words.

Perhaps there is more to design patterns than mindlessly complaining about stuff you don't fully understand.

The Flag Antipattern

I have a colleague which calls a higher-order function Reader pattern which is obviously absurd.