从 if else 到 switch case 再到抽象.docxVIP

大家觉得在接手遗留代码时，见到什么东东是最让人感到不耐烦的？复杂无比的 UML ？我觉得不是。我的答案是，超过两个 else 的 if ，或者是超过两个 case 的 switch 。可是在代码中大量使用 if else 和 switch case 是很正常的事情吧？错！绝大多数分支超过两个的 if else 和 switch case 都不应该以硬编码（ hard-coded ）的形式出现。复杂分支从何而来首先我们要讨论的第一个问题是，为什么遗留代码里面往往有那么多复杂分支。这些复杂分支在代码的首个版本中往往是不存在的，假设做设计的人还是有点经验的话，他应该预见将来可能需要进行扩展的地方，并且预留抽象接口。但是代码经过若干个版本的迭代以后，尤其是经过若干次需求细节的调整以后，复杂分支就会出现了。需求的细节调整，往往不会反映到 UML 上，而会直接反映到代码上。例如说，原本消息分为聊天消息和系统消息两类，设计的时候自然会把这设计为消息类的两个子类。但接着有一天需求发生细节调整了，系统消息里面有一部分是重要的，它们的标题要显示为红色，这时候程序员往往会做如下修改：在系统消息类上面加一个 important 属性在相应的 render 方法里面加入一个关于 important 属性的分支，用于控制标题颜色程序员为什么会作出这样的修改？有可能因为他没意识到应该抽象。因为需求说的是「系统消息里面有一部分是重要的」，对于接受命令式编程语言训练比较多的程序员来说，他或许首先想到的是标志位──一个标志位就可以区分重要跟不重要。他没想到这个需求可以用另一种方式来解读，「系统消息分为重要和不重要两种类别」。这样子解读，他就知道应该对系统消息进行抽象了。当然也有可能，程序员知道可以抽象，但基于某些原因，他选择了不这样做。很常见的一种情况就是有人逼着程序员，以牺牲代码质量来换取项目进展速度──加入一个属性和一个分支，远比抽象重构要简单得多，如果要做10个这种形式的修改，是做10个分支快还是做10个抽象快？区别显而易见。当然， if else 多了，就有聪明人站出来说「不如我们改成 switch case 」吧。在某些情况下，这确实能够提升代码可读性，假设每一个分支都是互斥的话。但是当 switch case 的数量也多起来以后，代码一样会变得不可读。复杂分支有何坏处复杂分支有什么坏处？让我从百度 Hi 网页版的老代码里面截取一段出来做个例子。switch (json.result) {? case ok:? ? switch (mand) {? ? ? case message:? ? ? case systemmessage:? ? ? ? if (json.content.from == ? ? ? ? ? json.content.content == kicked) {? ? ? ? ? /* disconnect */? ? ? ? } else if (mand == systemmessage? ? ? ? ? || json.content.type == sysmsg) {? ? ? ? ? /* render system message */? ? ? ? } else {? ? ? ? ? /* render chat message */? ? ? ? }? ? ? ? break;? ? }? ? break;这段代码要看懂不难，因此我提一个简单问题，以下这个 JSON 命中哪个分支：{? result: ok,? command: message,? content: {? ? from: CatChen,? ? content: Hello!? }}你很容易就能得到正确答案：这个 JSON 命中 /* render chat message */ （显示聊天消息）这个分支。那么我想了解一下，你是如何作出这个判断的？首先，你要看它是否命中 case “ok”: 分支，结果是命中了；然后，你要看它是否命中 case “message”: 分支，结果也是命中了，所以 case “systemmessage”: 就不用看了；接下来，它不命中 if 里面的条件；并且，它也不命中 else if 里面的条件，所以它命中了 else 这个分支。看出问题来了吗？为什么你不能看着这个 else 就说出这个 JSON 命中这个分支？因为 else 本身不包含任何条件，它只隐含条件！每一个 else 的条件，都是对它之前的每一个 if 和 else if 进行先非后与运算的结果。也就是说，判断命中这个 else ，相当于判断命中这样一组复杂的条件：!(json.content.from == json.content.content