代码重构实例

　　给一个已有项目增加新需求时发现，原有项目中存在大量重复代码，每个处理前台的请求的方法中，参数检查、权限认证、异常处理代码都是一样的，而真正的业务逻辑就被这一段段的重复代码淹没了，重复代码的结构如下：

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中设计模式，但以上具体使用了哪种模式，我还一脸懵逼，等有时间对上号了再填坑，但有时间就等于很久很久以后。