Patterns are about giving developers a common vocabulary so they can discuss what they all do without having to go into insufferable detail each time. We all do lots of the same shit and it's extremely helpful to all use the same names for those things.
Why do I have to call it "the strategy pattern?" What was wrong with "passing in a function?" Giving it a name like that obscures the idea. Yes, I realize that if you don't have first-class functions you have to work around that with interfaces or similar, but now we're describing a workaround for a language limitation, which seems a bit less inspiring than what "design patterns" are sold as.
I think the word "strategy" encapsulates more about the semantics than "passing in a function".
For example, the "visitor" pattern could also be described as "passing in a function", but there's a significant difference: a visitor is intended to be called on each element of a data structure in turn (i.e. a bit like an iterator callback), while a strategy defines an algorithm that you're expecting the caller to select at run-time (e.g. different cipher implementations).
Syntactically, they may well be the same ("passing in a function") but semantically, they're very different.
It can be useful to be able to have this shared vocabulary when talking about designs.
"Visitor" has always bothered me too. If you look it up it's tons and tons of text to describe "pass in a function and descend a graph calling it on each node."
That's actually not what the visitor pattern is about, though the way it's typically presented and the poor name tends to confuse the fact. Visitor isn't about traversing trees. It's about letting you define class-specific behavior outside of the definition of the class itself.
It gives you a way to "add a method" to a set of classes without actually stuffing them in the class definitions themselves.
In practice, most visitor patterns are used with AST classes or other types that are stored in a tree-like fashion, but that's coincidence. The visitor pattern itself is really about using virtual dispatch to avoid an ugly and non-type-safe type switch.
> If you look it up it's tons and tons of text to describe "pass in a function and descend a graph calling it on each node."
No, it's one word: visitor. That's the point, we can now avoid saying "pass in a function and descend a graph calling it on each node" and instead simply say visitor and everyone knows what we mean without the big long explanation.
Sure, so some documentation isn't great (and, by having lots of documentation, you might be a bit disappointed at how simple it ends up being).
...but going back to my original point, isn't it more valuable to have a common vocabulary, meaning that I can say "visitor" rather than "pass in a function and descend a graph calling it on each node"?
Well, in my opinion, no, because the fancy terminology obscures the simple idea.
Also, the naming of the pattern, along with implementation, may push people to copy a design that would be the best way to do it in C++ or Java ca. 2000 but unnatural in whatever they're working in.
It's a simple word, visitor; that's not fancy terminology. Giving things names is not fancy, it's practical and it aids in communicating with other people who do the same thing. You're basically objecting to the fact that people like to give names to their idioms so they communicate better.
You don't have to call it anything, language doesn't work that way, but using the same words other people use makes communication more efficient. Passing in a function is vague and unspecific and doesn't fully encapsulate the idea of a strategy.
