代碼重構實例

　　給一個已有項目增加新需求時發現，原有項目中存在大量重複代碼，每個處理前臺的請求的方法中，參數檢查、權限認證、異常處理代碼都是一樣的，而真正的業務邏輯就被這一段段的重複代碼淹沒了，重複代碼的結構如下：

public Response getResult(String request){
    if(參數檢測失敗){
        return response(code 400);
    }
    if(權限檢測失敗){
        return response（code 403);
    }
    try{
        ***真正的業務邏輯***
        return response(code 200);
    }catch(Exception e){
        return response(code 500);
    }
}

　　同一個給UI的資源類中，存在五段以上的代碼，而後續增加接口也還是需要做這些梳理。項目中存在大量重複代碼的弊端不需要我多說，經過設計後，開始重構代碼。因爲組裝返回碼的代碼都已存在，爲了複用原代碼，並減少重複代碼，做如下改動：
　　新定義一個接口，其中有一個抽象方法execute():

public interface Handler{
    public Response execute(String... params);
}

　　在原來的資源類中增加一個公共的私有方法（沒有定義再新的類，是因爲實際的業務代碼中用到了資源類中的其他私有方法，比如從請求中拿到用戶名），如下：

private Response dealMethod(Handler handler,String... params){
    if(參數檢測失敗){
        return response(code 400);
    }
    if(權限檢測失敗){
        return response（code 403);
    }
    try{
        return handler.execute(String... params);
    }catch(Exception e){
        return response(code 500);
    }
}

　　使用String… 不定長度的參數，是因爲資源類中每個處理請求的方法中的參數不固定，但還好因爲是UI接口，參數都是String，否則就得使用Object…來處理了。
　　最後，是資源類中原有的處理請求的方法，具體業務邏輯只需實現在Handler的execute方法中，即可實現業務分離：

public Response getResult(String request,String id){
    return dealMethod(new Handler(){
                public Response execute(String... params){
                    String request = params[0];
                    String id = params[1];
                    //具體的業務邏輯
                }
            },request,id);
}

　　以下爲吐槽：

如果項目中有使用到Spring，那可以使用aop，簡單而又高大上，然而這個項目並沒有；據小夥伴說，AOP可獨立使用，引個jar包就行。但沒有必要時，真心不想額外引第三方jar包。自己玩玩隨意，但在項目中，每個jar包都是地雷啊。

雖然看過一遍23中設計模式，但以上具體使用了哪種模式，我還一臉懵逼，等有時間對上號了再填坑，但有時間就等於很久很久以後。