From if else to switch case to abstract

What do you think is the most boring thing to see when you take over the legacy code? A complex UML? I don't think so. My answer is, more than two else if, or switch for more than two case. But is it normal to use a lot of if else and switch case in your code? Wrong! Most of the more than two of the if else and switch case should not appear as hard coded (hard-coded).

Where complex branches come from

The first question we have to discuss is why there are so many complex branches in the legacy code. These complex branches often do not exist in the first version of the code, assuming that the person doing the design has a bit of experience, he should anticipate where it might need to be expanded in the future, and reserve the abstract interface.

However, after several iterations of the code, especially after several adjustments to the requirements details, the complex branches appear. The need for detail adjustment, often not reflected in UML, but will be directly reflected in the code. For example, the original message is divided into two types of chat messages and system messages, design will naturally be designed as a message class of two subclasses. But then one day the need for detail adjustment, the system message is part of the important, their title to be shown in red, when the programmer will often do the following modifications:

1. Add a important attribute to the system message class

2. Add a branch of the important property to the corresponding Render method to control the caption color

Why would programmers make such a change? Maybe it's because he didn't realize that he should be abstract. Because demand says "part of the system message is important", for programmers who are trained more in the imperative programming language, the first thing he might think of is the sign bit--a sign bit that distinguishes between important and unimportant. He didn't think the demand could be interpreted in another way, "system messages are divided into two categories, important and unimportant." In this way, he knew that the system message should be abstracted.

It is possible, of course, that the programmer knows it can be abstracted, but for some reason he chooses not to. One of the most common situations is that someone is forcing a programmer at the expense of code quality in exchange for the speed of the project--adding a property and a branch, much simpler than the abstract refactoring, if you want to do 10 of this form of modification, is to do 10 branches fast or 10 abstract fast? The difference is obvious.

Of course, if more, there are wise people come out and say, "Let's switch case". " In some cases, this can actually improve the readability of the code, assuming that each branch is mutually exclusive. But when the number of switch case is also more, the code will become unreadable.

What's the downside of complex branching?

What's the downside of complex branching? Let me from the Baidu Hi Web version of the old code to intercept a paragraph out to do an example.

switch　(json.result)　{
　　 case　"ok":
　　　　 switch　(json.command)　{
　　　　　　 case　"message":
　　　　　　 case　"systemmessage":
　　　　　　　　 if　(json.content.from　==　""
　　　　　　　　　　 &&　json.content.content　==　"kicked")　{
　　　　　　　　　　 /*　disconnect　*/
　　　　　　　　 }　else　if　(json.command　==　"systemmessage"
　　　　　　　　　　 ||　json.content.type　==　"sysmsg")　{
　　　　　　　　　　 /*　render　system　message　*/
　　　　　　　　 }　else　{
　　　　　　　　　　 /*　render　chat　message　*/
　　　　　　　　 }
　　　　　　　　 break;
　　　　 }
　　　　 break;