In Doctor Who the character Kamelion was a robot which could take any form. The physical prop they used was allegedly very troublesome and only understood by its creator, who wasn’t around to help put it right.
So to the Chamelion function …
Consider this code:
There’s a fair bit going on above. Let’s just understand it. Some sort of request comes in, and we can make a basic query from it. Then based on the field provided by the caller, we add a criterion to the query using that field and pulling an operand out of the request.
On top of that we have to throw an error if the caller provides a field we don’t know how to query.
What’s wrong with this function?
I’ll Tell You What’s Wrong…
It’s not a function. It’s two functions. See also Both Kinds of Music.
The calling code might look like this:
We’re using a choice of string to control half the flow of a single function.
It’s worse than that… we need an exception to throw when some caller invents a string we’ve never heard of.
Let’s just refactor this a second:
By splitting this into two functions, it’s self-documenting, easier to follow and doesn’t need to handle rogue strings. It’s probably slightly faster, but that’s not really a major driver.
But What About The Duplication?
I suspect that one driver to chameleon functions is a misguided attempt to reduce code duplication. Please note that the above has examples of code being reused across the two functions – createQueryFrom but has independent logic in each. It’s not duplicated code.
The example I drew this from may originally have had more than one line of code where we now see createQueryFrom this may have driven a feeling of fear of duplication, which in turn created the monster. Refactor relentlessly to reduce the right duplication and these sorts of things won’t happen.