The point is that the desired mapping is known not just at compile time, but is explicitly known to the programmer. So it is clearer if it right there in the executable code rather than hidden away in some moving part (the mapping data structure).
So it is clearer if it right there in the executable code rather than hidden away in some moving part (the mapping data structure).
Following several levels of nested if/else is "clearer" than going to the right array index? I don't know what you mean by "hidden away in some moving part".
The moving appart that gets hidden away is the table (or more often, Hack mandictionary) that is stored somewhere in memory. If you are lucky, it is stored statically. It is never defined in quite the same place as the decision that it implements.
Unless you're optimizing for performance (which is rare in my domain), control-flow statements are a smell and should be avoided. Each branch has some "implicit" state that is being fragmented and has to be manually managed by the programmer.
Midway between nested conditionals and lookups is using flags and a tablesque series of conditionals. Redundant but easily understood (and therefore testable).
I first learned about this technique from Code Complete (linked in the TFA). IIRC, McConnell used the term "truth tables".
"...since the code is far less branchy."
Code construction GoF style Design Patterns just introduce another level of indirection. That's it. (Insert cliche here.)
"Design Patterns" are overused, especially in the Java world (eg J2EE/Spring, Service Providers, Strategies, DI, IoC).
The "design" part is figuring out the least complicated balance between conditional branches and call stack depth, between composition and inheritance.