代码精简之路-责任链模式

标签：return service 角色代码之路 VIP 精简普通用户 public

前言

常说c#、java是面向对象的语言，但我们平时都是在用面向过程的思维写代码，实现业务逻辑像记流水账一样，大篇if else的判断；对业务没有抽象提炼、代码没有分层。随着需求变化、功能逐步拓展、业务逻辑逐渐复杂；代码越来越长、if else嵌套越来越多，代码会变成程序员都厌恶的"屎山"。这种代码后期维护成本非常高、牵一发而动全身、改一处逻辑战战兢兢。假如我们完成开发任务交差，后期维护不关自己的事；但是长期做重复的CRUD、记流水账对我们没有好处。虽然项目不是自己的，但是时间是自己的，这样几年过去似乎没有精进变化，长期下去年龄增大会逐渐丧失竞争力。

下面记录今天开发的一个小功能，演示一步一步重构的过程。

需求

有一个智能识别的api给用户调用。角色有两个：管理员、普通用户。管理员不限次数调用，普通用户每日限用五次。

简单实现，只判断如果是普通用户就检查次数，不满足就返回提示：

if (service.isNormalUser() && service.freeNumUseUp()) {
    return AjaxResult.error("普通用户免费识别次数已使用完！");
}

// todo:调用识别接口

功能演变：普通用户可充值后升级为VIP用户，VIP用户在有效期内不限次数使用，过期以后降为普通用户。
增加VIP角色的检查后：

if (service.isVipUser() && service.vipUserExpire()) {
    return AjaxResult.error("会员已到期！");
}
if (service.isNormalUser() && service.freeNumUseUp()) {
    return AjaxResult.error("普通用户免费识别次数已使用完！");
}

// todo:调用识别接口

以上修改的问题：普通用户充值以后，是增加一个VIP的角色而不是把原普通用户角色更新为VIP角色。此时这个用户有两个角色，那么上面的代码先判断VIP角色是否到期是没问题的，但是下面又判断了是否为普通用户就有问题了，因为他有两个角色呀，VIP未到期时第2个条件也满足了会给出不合理的提示。怎么改，首先想到的是不是检查VIP后就不检查普通用户了？于是修改为：

if (service.isVipUser()) {
    if (service.vipUserExpire()) {
        return AjaxResult.error("会员已到期！");
    }
} else {
    if (service.isNormalUser() && service.freeNumUseUp()) {
        return AjaxResult.error("普通用户免费识别次数已使用完！");
    }
}

// todo:调用识别接口

以上仍然有问题，如果是VIP角色就不会检查普通用户角色了，可是按需求VIP到期以后他还具有普通用户角色，可以在每天免费次数内使用。于是再改：

boolean dontPass = service.isVipUser() && service.vipUserExpire();
if (dontPass) {
    dontPass = service.isNormalUser() && service.freeNumUseUp();
    if (dontPass) {
        return AjaxResult.error("普通用户免费识别次数已使用完！");
    } else {
        return AjaxResult.error("会员已到期！");
    }
}

// todo:调用识别接口

以上修改可以满足VIP和普通用户的检查了，还差了管理员的判断，还要再嵌套：

boolean dontPass = !service.isAdmin();
if (dontPass) {
    dontPass = service.isVipUser() && service.vipUserExpire();
    if (dontPass) {
        dontPass = service.isNormalUser() && service.freeNumUseUp();
        if (dontPass) {
            return AjaxResult.error("普通用户免费识别次数已使用完！");
        } else {
            return AjaxResult.error("会员已到期！");
        }
    }
}

// todo:调用识别接口

终于满足3个角色的检查了，加了3层if判断。以后再出现新的角色怎么办？如果功能交给同事来升级，原来的代码轻易不敢动只能再嵌套。

梳理以上需求，3个角色有任意一个通过就可以了。实际上检查时可以按以下先后顺序逐个过，最后一个不满足才返回提示。

a. 是否有管理员角色，否进入下一级
b. 是否有VIP角色且未到期，否进入下一级
c. 是否有普通用户角色且满足免费次数条件，否进入下一级；如果没有下一级则检查不通过。

重新设计

审批角色接口，主要两个功能：a. 角色判断(当前用户是否为本角色)，b. 是否检查(审批)通过

public interface IAudit {
    /**
     * 角色判断：是否为我的责任
     *
     * @return
     */
    boolean isMyDuty();
    
    /**
     * 是否通过
     *
     * @return
     */
    boolean auditPass();
    
    /**
     * 检查(审批)意见：不通过时返回空字符串
     *
     * @return
     */
    String auditMessage();
}

审批角色抽象类，实现审批角色接口，并且是3个角色实现类的父类，充当审批角色接口和角色实现类的中间过度。作用是判断检查(审批)是否通过，这里不大容易理解，实际3个角色的实现类分别实现接口就可以了，没有这个中间过度也可以的。为什么要加这个中间类？因为最终检查是否通过要调用isMyDuty和auditPass两个方法，这里可以把这两个方法的调用合并为一个方法，其实就是把判断角色和角色的检查条件统一在这个类而不是在3个实现类里去分别写了，为什么？因为3个实现类要写的判断都是完全一样的代码isMyDuty()&&auditPass()，作用就是本来要写3行，现在只写1行。看上去没有必要？因为现在只有3个类呀，如果以后扩展到5个角色，5类那多了。还有，如果是功能修改呢，那就要6个类里分别改了。每改一个类都需要针对这个类单独测试。修改测试花时间多了，这里只有一次修改测试。

public abstract class AbstractAudit implements IAudit {
    /**
     * 角色是否检查通过
     *
     * @return
     */
    public boolean checkPass() {
        return isMyDuty() && auditPass();
    }
}

3个角色的实现类。

管理员:

@Service
public class AdminAudit extends AbstractAudit {
    @Autowired
    private IdentifyService identifyService;
    
    @Override
    public boolean isMyDuty() {
        return identifyService.isAdmin();
    }
    
    @Override
    public boolean auditPass() {
        return true;
    }
    
    /**
     * 管理员是没有限制的，所以没有提示
     *
     * @return
     */
    @Override
    public String auditMessage() {
        return "";
    }
}

VIP用户：

@Service
public class VipUserAudit extends AbstractAudit {
    @Autowired
    private IdentifyService identifyService;
    
    @Override
    public boolean isMyDuty() {
        return identifyService.isVipUser();
    }
    
    @Override
    public boolean auditPass() {
        return !identifyService.vipUserExpire();
    }
    
    /**
     * 这里还需要优化，因为isMyDuty和auditPass可能被调用两次，可以将isMyDuty、auditPass返回值存在临时变量中
     *
     * @return
     */
    @Override
    public String auditMessage() {
        if (!isMyDuty()) {
            return "不是会员";
        } else if (!auditPass()) {
            return "会员过期";
        }
        return "";
    }
}

普通用户：

@Service
public class NormalUserAudit extends AbstractAudit {
    @Autowired
    private IdentifyService identifyService;
    
    @Override
    public boolean isMyDuty() {
        return identifyService.isNormalUser();
    }
    
    @Override
    public boolean auditPass() {
        return !identifyService.freeNumUseUp();
    }
    
    @Override
    public String auditMessage() {
        return "普通用户免费识别次数已使用完";
    }
}

审批责任链类。作用为添加审批人、审批返回结果。

public class AuditChain {

    private List<AbstractAudit> chain = new ArrayList<>();

    /**
     * 添加审批人
     *
     * @param auditor
     */
    public void add(AbstractAudit auditor) {
        chain.add(auditor);
    }


    /**
     * 检查/审批
     *
     * @return
     */
    public Result audit() {
        Result result = new Result();
        // 是否检查通过
        boolean pass = chain.stream().anyMatch(a -> a.checkPass());
        result.setPass(pass);
        if (!pass) {
            String msg = chain.stream().map(c -> c.auditMessage()).filter(m -> Strings.isNotBlank(m)).collect(Collectors.joining(","));
            result.setMsg(msg);
        }
        return result;
    }


    @Data
    public class Result {
        private boolean pass;
        private String msg;
    }
}

实现检查

// 审批责任链中加入3个角色,这里用的Spring Boot开发，3个角色都是容器注入的，其它框架中手动创建实例

// 添加审批人角色
auditChain.add(adminAudit);
auditChain.add(vipUserAudit);
auditChain.add(normalUserAudit);

// 审批结果
AuditChain.Result auditResult = auditChain.audit();
if (!auditResult.isPass()) {
    return AjaxResult.error(auditResult.getMsg());
}

总结

最终的实现代码简洁明了，易维护、易扩展升级：

核心方法只有auditChain.add和auditChain.audit，一眼看去就能明白作用是加入审批人和实现审批。
如何扩展功能加入其它角色？创建新的角色类并继承AbstractAudit，并加入到责任链中。不需要在原来的if中嵌套了。
现在的检查是多个角色中有任意一个通过即可，转换到审批场景就是多角色审批，其中一个角色审批通过即可。如果要需求改成多个角色全部审批通过才行呢？其实就是责任人链中or的关系改为and关系。只需要修改AuditChain类的audit方法，将chain.stream().anyMatch改为chain.stream().allMatch。anyMatch表示任意一个匹配，allMatch表示全部匹配。如果要在改造前的代码中要实现or到and的变化，原有代码几乎要完全重写。

学习交流：

标签：return,service,角色,代码,之路,VIP,精简,普通用户,public
From： https://www.cnblogs.com/cy2011/p/18572619

代码精简之路-责任链模式

前言

需求

重新设计

总结

相关文章

赞助商

阅读排行