对编码规范有一定要求的开发者，多少应该知晓《重构》和《代码整洁之道》这两本书，在对"Switch Case"的看法上，两位作者的观点都是一致的——被认作是坏味道。
在业界，有很多开发者受这一观点的影响颇深，但凡遇到"Switch Case"，就巴不得消除。通常的消除方法有两种：
1. 通过策略或者状态模式消除(也是书中的方法)；
2. 通过Dictionary来消除
以下是我的一些观点：
#1 如果有n个case节点，且每一节点下的表达式很少，有时仅仅只是一个行为或一行代码去修改一个状态，我们为了消除这种“坏味道”，不得不派生n个concrete在暴露在工程目录下，每个concrete中的实现也都极小。这无疑增加了工程结构的复杂度。对于这种情况，我认为这样的消除所带来的副作用远大于它本身的"坏味道"，说白了，它仅仅是把一种复杂度转换成了另一种复杂度。
#2 这是一种为了消除而去消除的办法。首先搞清楚一点，为什么认为"Switch Case"是坏味道，其最大的一个原因是违反了开闭原则。那么通过构建Dictionary显然是不能消除违反了开闭原则这个事实的，其本质上只是替换一种方式，并没有做到消除。
结论："Switch Case" 如同冗长的 "If else"一样，它的出现有时的确是坏味道，它导致方法过长，职责不单一，抽象级别模糊不清等等问题；但有的时候也并不是那么坏，至少在看到这样的代码时，应该有一个自己的判断，不要盲目的去信奉某一本书或者某一种观点。
转载于:https://www.cnblogs.com/dryobjects/p/6742143.html
