项目经过长期多人的维护，所谓人多手杂，出现不少过多过长的switch-case分支，或者多重switch-case嵌套。每每添加功能，我都会紧皱眉头，然后带着罪恶感向已经成百上千行的函数里再添上一个case分支，然后纠结地收工了事。
于是乎，在我的内心深处，switch-case俨然成了代码坏味道的代名词，写代码时总小心翼翼地避开它们，可往往又事与愿违。
事实上，switch-case语句并不是代码坏味道的根源，坏味道来自糟糕的结构设计，过多的switch-case分支，多重switch-case嵌套，这些都将导致代码可读性下降，维护困难易出错。
对于分支有多又长的switch-case分支，可是使用表驱动方法或者在特定情况下可以采用表驱动方法结合事件机制进行分解。
对于表驱动方法，可用数组或std::map将case判定常量映射到相应的处理函数。核心代码实现类似如下：
// 分支判定枚举
enum CASE
{
_CASE_A,
...
_CASE_X,
_CASE_AMOUNT // 分支总数
};
// 处理函数类型
typedef void (*HANDLER)(void);
// 映射
HANDLE handlers[_CASE_AMOUNT] =
{
&HandlerA,
...
&HandlerX
};
bool handler(UINT uEvent)
{
if (uEvent < _CASE_AMOUNT)
{
(*handlers[uEvent])();
return true;
}
return false;
}
优点：条理清晰易于阅读。
缺点：要增添很多处理函数，且不便于跟踪调试。
对于在一个公共对象里使用switch-case分支集中处理大量与该对象无紧密逻辑关联事件的情况。可通过在公共基类中使用事件处理机制，实现事件与监听器（与事件相关的对象，如窗口）的映射，事件的分配处理。相关代码如下：
class CBase
{
...
public:
// 添加事件监听器
static bool AddEventListener(UINT uEvent, CBase* pListener);
// 移除事件监听器
static bool RemoveEventListener(UINT uEvent, CBase* pListener);
// 将事件给相应监听器处理
static void DispatchEvent(UINT uEvent);
// 处理事件，该虚函数由监听器实现
virtual void OnEvent(UINT uEvent, int nParam) {}
...
private:
// 事件与监听器的映射，多个监听器可监听同一个事件
static std::multimap<UINT, CBase*> m_mmapEventListener;
...
}
对于事件处理机制，在Java等语言中有大量使用，这里就不贴一大段代码了。
优点：逻辑性强，耦合度低，符合开放封闭原则。
缺点：事件分配时效率较switch-case分支低。