If-else optimization

Optimization of excessive if-else branches

More than 3 should be optimized, saying that too many branches of if-else can be optimized using switch or responsibility chain mode. Sure, this is a small problem, but we can still sort out the refactoring of this little problem.

Why optimize?

You have not read the wrong. This is to be put in the first article to talk about.

Many people will say that the code is not elegant when stacked up a bunch of if-else branches. But, how to define the concept of "elegance"? One more step, even if it's not "elegant", what's the problem?

For an ordinary code like this:

12345678

int code;if("Name".equals(str))    code = 0;else if("Age".equals(str))    code = 1;else if("Address".equals(str))    code = 2;...

There can be many refactoring options, but using such code, though rudimentary, does not, in most cases, affect anything, such as maintainability. Of course, if you find that there is a bad side to it, consider refactoring it. In other words, usually you first have to say the problem of a piece of code (for example, you think this code does not conform to the open and closed principle, because you want to keep the code close and stable), then there is the need to refactor, and not always use "elegant" and "concise" to avoid the question. Almost all of the books say to write elegant, concise code, which is understandable, but things need to use their own judgment, but not to be habitually brainwashed.

In my previous company, is a typical communication and traditional software companies, code quality is generally good, but many times, you will see a lot of not elegant code-perhaps you think not concise, beautiful, but the code is rigorous, clear, I think this is very good. Conversely, some ingenious designs may bring about a decline in readability and understandable behavior.

Find a way to substitute for branch judgment

Then we'll think about how to refactor to optimize too many if-else branches.

The most basic component of program logic is branching, judging and looping. Too much if-else is due to the fact that at some point of change there are many judging conditions and results branching. So the most basic solution is to synthesize a plurality of judgment conditions, that is, to synthesize a number of branches.

In most cases, however, the branch of the conditional judgment cannot be merged. So, we need to wrap this point of change in another way, rather than using If-else.

1. Using a map to do this, If-else's change point uses the map's Get method instead:

123456

< Code class= "Java plain" >map typecodemap = new HashMap (); typecodemap.put ( 0 typecodemap.put ( 1 typecodemap.put ( 2 ... int code = Typecode.get (type);

2. Enumeration:

1234567891011

public enum Codes {    Name(0), Age(1), Address(2);        public int code;    Codes(int code){        this.code = code;    }}//使用：int code = Codes.valueOf(str).code;

3. Polymorphism:

12	ICode iCode = (ICode)Class.forName("com.xxx."+ str).newInstance();intcode = iCode.getCode();

Of course, this is not an appropriate way to simplify the branching judgment logic, if only considering conversions from string to int. Of course, such a way is often used to make conversions from strings to specific objects.

There are some friends said this mode to solve the problem of multi-if-else, these are correct, of course, there is no exception based on polymorphism to achieve, so I do not mention. These are good, at least more valuable than the old saying switch to replace if-else:)

Finally, for such a small issue, I would like to add that I do not see large if-else and not see the big new keyword, I think this is a lot of Java programmers have ideas or habits, or even common problems-this is not good. The most valuable part of Java is not its semantic syntax or its virtual machine cross-platform and high performance, but in its community its incredibly rich class library, in which the people who use it can think in terms of design and macro. But Java programmers, including me, can easily take this path too far, such as the Factory of the Earth, such as the configuration of the hills and the hills, such as the reusable code will never be reused, such as the extensible code will never be extended, as well as from the front to the back from the inside to the outside of the hierarchy, layer after layer. In the endless pursuit of these aspects, we are still focused on the problem to be solved, write some more clearly usable code.

If-else optimization