Multiple Dispatch
I believe the pattern you describe is called multiple dispatch.
In languages that support multi-methods (e.g. Clojure), this is not a problem at all because the language itself can express this relationship between a specific value and a function that needs to be called for it.
The way you're solving the problem is just the natural way to do it when you don't have multiple dispatch support built in the language.
Alternatively, you could have used switches or tables (e.g. a map).
switch processingType { case CONFABULATION: return confabulation(data); case RETICULATION: return reticulation(data); case SPLICE: return splice(data); } Additionally, if your language supports functional programming, you could have a table do that multiple dispatch for you.
dispatch[CONFABULATION] = confabulation dispatch[RETICULATION] = reticulation dispatch[SPLICE] = splice Then you can simply do:
dispatch[processingType](data) On the Subjective Interpretation of Patterns
Since others have commented on the subjectivity of patterns, I wanted to add a few quotes here and hopefully contribute to that part of the discussion as well.
The famous Design Patterns book, whose authors are often referred to as the Gang of Four (GoF), clarifies from the start that patterns are subject to interpretation according to context.
Point of view affects one’s interpretation of what is and isn’t a pattern. One person’s pattern can be another person’s primitive building block.
Later in that same introductory chapter, it says:
The choice of programming language is important because it influences one’s point of view. Our patterns assume Smalltalk/C++-level language features and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called “Inheritance,” “Encapsulation,” and “Polymorphism.” Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor […] In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other.
So, you probably wouldn’t think of inheritance as a pattern if you were working with a language that fully supports it. However, in languages without support for it, you would resort to other tricks to simulate inheritance when you need it (consider e.g. how Google Go uses struct composition and some syntactic sugar to make us feel we have a form of struct inheritance using embedded fields and some method set resolution voodoo).
Another example, in GoF’s book we find a pattern called decorator, but developers of functional programming languages are pretty used to it under a fundamental feature of their languages: high-order functions. They probably never think about needing a pattern for that since it is so ingrained in their languages and languages shape the way we think.
On Strategy Pattern
Others answers already discuss it, so I will try to contribute new angles to the analysis.
In functional languages, the so called strategy pattern is just a regular function that encapsulates an algorithm. In OOP languages the function is encapsulated in a object (called strategy) that you use to reach the function inside (that’s the case of e.g. Java).
What matters with patterns is to understand the problem they solve and the tradeoffs of using them. Implementations might defer depending on language features.
In your case, what matters is that it is better to have individual functions managing separate types of processing than having a single function with code bifurcations based on the enum value. The latter can rapidly become a maintenance nightmare.
“The flow of the switches themselves becomes confusing. Hard to read. Hard to decipher. When a new case comes in, the programmer must find every place it can be involved (often finding all but one of them). I like to call this “switch creep.”
Design Patterns Explained by Alan Shalloway
However, once again, you resort to functions, or strategies or whatever you have there to circumvent the fact that your language does not have multimethods support, because if it did, the strategy pattern would still be there, but you would call it something else.