Let me try to answer your questions:
Using multiple function heads is ‘sort of’ the same thing as a switch-case, but more powerful.
In languages like C and C++, you are only allowed to use int-like values in a switch case, as these can be optimized by the compiler to a direct jump at best, or a binary search at worst. Therefore, things like strings are not allowed.
In most imperative or object-oriented interpreted languages, however, this optimization does not happen. You are allowed to use any value in a switch statement, but this is treated as just syntactic sugar for an if ()... else if () ... else if ()...-chain.
In languages like Elixir that support pattern-matching, however, the case statement is a lot more powerful than a plain 'ol switch: The compiler will recognize what properties you are trying to ascertain of your data types, and underwater write the appropriate checks that only check what needs to be checked; redundant checks are not performed.
While this is of course marginally less fast than the ‘direct jump’ approach that C/C++ support, it is a lot faster than a simple if... else if-chain. And on the other hand, it makes for extremely readable code.
The compiler will take function with multiple heads (it does not matter if it is a named or anonymous function, it works the same way), and rewrite these multiple heads using a case-statement underwater. So yes, in this way, they are doing the same thing.
But from a code organization perspective, it usually is better to separate your functionality in many small named functions, because it makes it easier in the future to change only a small part.
In the case that a pattern is matched in a function head or in a case statement, only the variables that are part of that statement are available (also available are the ones before the function or case statement, but notably not the ones named in the other functin heads / case matches).
EDIT: @tyro was a little bit faster than me
, but I hope you still find my background explanation helpful or at least entertaining
.






















