Optimization of too many if-else branches

If-else too many branches can be optimized using the switch or responsibility chain mode. Indeed, this is a small problem, but we can still sort out the reconstruction method of this small problem. Why optimization? You are not mistaken. This is the first article. Many people will say that the Code is not elegant if-else branches are stacked. But how can we define the concept of "Elegance? Let's just take a further look at the question, even if it is not "elegant? For such a piece of Common code: 1 2 3 4 5 6 7 8 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 methods, but such code is simple, but in most cases it does not affect the maintainability, for example. Of course, if you find that there is really a bad side, you should consider restructuring it. In other words, you usually need to talk about a code segment first (for example, you think this code does not conform to the open/closed principle, because you want to keep this code closed and stable ), then there is a need for restructuring, rather than always using "Elegance" and "conciseness" to block questions. Almost all books say that they want to write elegant and concise code. This is understandable in itself, but things need to be judged by themselves, so don't get brainwashed habitually. In my previous company, I was a typical communication and traditional software company. The code quality is generally good, but many times, you will see a lot of code that is not elegant enough-maybe you think it is not concise and beautiful, but the code is rigorous and clear, I think this is very good. On the contrary, some exquisite designs may cause problems of readability and comprehension reduction. Find a way to replace the Branch judgment. Next, let's consider how to refactor and optimize too many if-else branches. The most basic components of program logic are branch, judgment, and loop. Excessive if-else is caused by many judgment conditions and result branches at a certain point of change. Therefore, the most basic solution is to combine multiple judgment conditions into one branch. However, in most cases, the branch of the condition judgment cannot be merged. Therefore, we need to encapsulate this change point in other ways, instead of using if-else. 1. you can use a Map to replace the if-else change point with the Map get method: 1 2 3 4 5 6 Map typeCodeMap = new HashMap (); typeCodeMap. put ("Name", 0); typeCodeMap. put ("Age", 1); typeCodeMap. put ("Address", 2 );... int code = typeCode. get (type); 2. enumeration: 1 2 3 4 5 6 7 8 9 10 11 public enum Codes {Name (0), Age (1), Address (2); public int code; codes (int code) {this. code = code ;}// use: int code = Codes. valueOf (str ). code; 3. polymorphism: 1 2 ICode iCo De = (ICode) Class. forName ("com. xxx. "+ str ). newInstance (); int code = iCode. getCode (); of course, if you only consider switching from String to int, this method is not very appropriate to simplify the Branch judgment logic. Of course, this method is often used to convert strings to specific objects. Some friends say that this mode is correct to solve the problem of multi-if-else. Of course, it is basically implemented based on polymorphism, so I will not mention it. These are all good. At least they are more valuable than the old saying that using switch to replace if-else. :) finally, for such a small problem, I would like to add that, if-else is the same as the new Keyword. I think this is a common concept or habit of many Java Programmers-it is not good. The most valuable part of Java is not its semantic syntax, nor its virtual machine cross-platform and high performance, but its rich class libraries in its community, people who use it can think about problems from the design and macro perspective. However, Java programmers, including me, can easily take this path too far, such as factories everywhere, such as configuration in the wild, such as reusable code that will never be reused, for example, the extensible code that will never be extended, the layer from inside to outside, and the layer after layer. With respect to the endless pursuit of these aspects, we should focus on the problems to be solved, and write more clear and available code.