Abstract: in this article, we will continue to share and introduce the second "code optimization question" about Java interview. The main functions are: Based on the idea of "annotation + Enum enumeration + policy mode" based on Spring Boot, we often need to increase or decrease the judgment of if else or the value of constants in switch case in the optimization project.

Content: Recently, I saw a small partner who was looking for a job in Java back-end development leave a message, sent such an interview question to debug, and asked for the corresponding solution: "In a formal Enterprise Project, there will be more or less if else and if else judgment codes. If the judgment level is only 2 / 3 layers, it's reasonable, but if the level exceeds 7 / 8 layers, and even more than 10 layers (cover your face) , it may be a disaster for later maintainers. Moreover, if you need to add or delete a certain level of judgment, you will inevitably need to move the if else with more than 10 levels. If it happens that the change of this code is likely to affect the use of the C end, that is, the user end, it will be very bad. "

(Note: the above situation is the same as the effect of switch case code block stacking)!

Next, let's take a look at this code directly (talk is heap, show me the code is more realistic, too much is nonsense):

public class SwitchCaseExecute {

    public static CaseResponse execute(CaseRequest request){
        CaseResponse response;
        switch (request.getType()){
            case "A":
                response= methodA(request);
                break;
            case "B":
                response= methodB(request);
                break;
		   //.........
            default:
                response= methodC(request);
                break;
        }
        return response;
    }

    public static CaseResponse methodA(CaseRequest request){
        CaseResponse response=new CaseResponse();
        response.setResult("A"+request.getName());
        return response;
    }

    public static CaseResponse methodB(CaseRequest request){
        CaseResponse response=new CaseResponse();
        response.setResult("B"+request.getName());
        return response;
    }

    public static CaseResponse methodC(CaseRequest request){
        CaseResponse response=new CaseResponse();
        response.setResult("C"+request.getName());
        return response;
    }

    public static void main(String[] args) {
        CaseRequest request=new CaseRequest("A","This is the name");
        System.out.println(execute(request));
    }
}

As can be seen from the above code, if you need to add constant values C, D, E, F... And the "method operation logic" corresponding to each constant value, there is no doubt that you need to add many case s and the corresponding "method operation logic" in the execute() method!

Obviously, this method can realize functions, but from the perspective of "object-oriented thought" and "code simplicity", it is obviously a little redundant and "process oriented thought"!

Next, we optimize this redundant code from the perspective of annotation + Enum + policy mode. The expected effect is that we can dynamically increase or decrease the constant values corresponding to the above case s and their corresponding "method operation logic" in the form of one annotation. The completion process is as follows:

(1) First, we need to define an enumeration class CaseEnum containing the above case constant values. Its source code is as follows:

public enum CaseEnum {
    A("A"),
    B("B"),
    C("C"),
    ;

    private String type;
    CaseEnum(String type) {
        this.type = type;
    }
    //Omit getter setter method of type
}

(2) Next, we define the annotation CaseAnnotation, which will be used on the "method operation logic implementation class". Its source code is as follows:   

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CaseAnnotation {
    CaseEnum value();
}

For more information, see: http://www.mark-to-win.com/tutorial/51084.html