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