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 (p. 32).
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 (p. 33).
So, you can see that in a language with multi methods you wouldn’t be asking for the name of the pattern for this use case you have in the question, it would just be a building block of your language, just as you probably wouldn’t think of inheritance as a pattern in 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.