>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.
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.