实际案例进行代码设计演进：无状态的类

走了一些弯路

于 2023-11-21 18:40:16 发布

阅读量151

点赞数

分类专栏：架构设计 java基础文章标签： java 设计模式架构设计重构

本文链接：https://blog.csdn.net/zhanghailang1/article/details/134538290

版权

java基础同时被 2 个专栏收录

34 篇文章 0 订阅

订阅专栏

架构设计

6 篇文章 0 订阅

订阅专栏

面向过程

可能写出如下的流水代码，肯定是不可取的。

代码耦合，无法拓展，当计算逻辑变化时，可能影响到其他业务逻辑
没法对计算逻辑进行单元测试

/**
     * 派发任务
     * @param request
     */
    public void distributeTask(Request request) {
				check(request);
        。。。

        //任务实体
        Task task = generateTask(request);
        //计算服务费
        BigDecimal serviceFee = task.getTaskMoney().multiply(task.getServiceFeeRate()).setScale(2, RoundingMode.HALF_UP);
        task.setServiceFee(serviceFee);
        。。。。
        //保存任务
        save(task);
        。。。。
    }

封装计算进`Task`

第一步尝试将计算服务费逻辑封装进Task类中，是否有问题

@Data
public class Task {

    /**
     * 任务名称
     */
    private String taskName;

    /**
     * 任务Id
     */
    private String taskId;

    /**
     * 任务金额
     */
    private BigDecimal taskMoney;

    /**
     * 服务费率
     */
    private BigDecimal serviceFeeRate;

    /**
     * 服务费
     */
    private BigDecimal serviceFee;

		/**
		 * 计算服务费
		 */
    public void calculateServiceFee() {
        BigDecimal serviceFee = this.taskMoney.multiply(this.getServiceFeeRate()).setScale(2, RoundingMode.HALF_UP);
        this.setServiceFee(serviceFee);
    }
}

这样我们客户端service的调用就会是这样的

	 	  	//任务实体
        Task task = generateTask(request);
				//当然这一步是可以放在generateTask()方法中。
        //task.calculateServiceFee();

看起来service的调用是清晰了，但这是有代价的，我们要做的是降低代价，做到平衡。

代价就是Task类内多了一个职责，即计算逻辑的维护；

理论上Task类应当只会在一种情况下会变更：属性的变更，比如说增加一个属性TaskDescription。

违反了solid中的第一原则：单一职责。

封装计算进`Calculator`

既然service与实体Task承担不来他们不该应有的压力：Calculate，那我们来个压力转移。

定义一个计算器Calculator，专注于计算服务费。

Task可以定义为实体类/业务类，一定是有状态的

Calculator 定义为操作类/辅助类，无状态stateless

注意这两者是完全不同的

设计Calculator 有以下几种方案：

1.持有计算所需属性（有状态）

public class Calculator {

    private BigDecimal taskMoney;
    private BigDecimal serviceFeeRate;

    /**
     * 计算服务费
     * @return 计算结果
     */
    public BigDecimal calculateServiceFee() {
        return this.taskMoney.multiply(serviceFeeRate).setScale(2, RoundingMode.HALF_UP);
    }
}

缺点很明显

1.当Task属性变化时，此辅助类也跟着变化

2.线程不安全，多线程当多个Task需要计算时，会存在计算的值相互覆盖的场景

2.持有整个计算对象（有状态）

public class Calculator {

    private Task task;

    /**
     * 计算服务费
     * @return 计算结果
     */
    public BigDecimal calculateServiceFee() {
        return task.getServiceFee().multiply(task.getServiceFeeRate()).setScale(2, RoundingMode.HALF_UP);
    }
}

这种方案控制了Task变化时影响的Calculator 本身属性的变化，但是仍然存在线程安全的问题

3.不持有对象无状态设计

public class Calculator {

    /**
     * 计算服务费
     * @return 计算结果
     */
    public BigDecimal calculateServiceFee(Task task) {
        return task.getServiceFee().multiply(task.getServiceFeeRate()).setScale(2, RoundingMode.HALF_UP);
    }
}

这里的无状态设计我们保证了线程安全，又保证了单一职责，算是比较完善的情况。

4.面向接口的可拓展的无状态设计

对于上述的设计，我们可以通过继承来将具体的行为封装到子类中去。

4.1定义一个接口

public interface ICalculator<T> {

    BigDecimal calcualate(T t);
}

4.2 具体的计算服务类

比如说回到我们最初的需求，需要一个计算服务费的类，使用ServiceFeeCalculator 实现ICalculator。

如果需要新增其他计算类，比如说计算薪水的类，再增加一个具体的SalaryCalculator 即可。

完全做到了和业务逻辑的分离，使ICalculator是一个可拓展的无状态类.

/**
 * @author hailang.zhang
 * @since 2023-11-21
 */
public class ServiceFeeCalculator implements ICalculator<Task{

    @Override
    public BigDecimal calcualate(Task task) {
        return task.getServiceFee().multiply(task.getServiceFeeRate()).setScale(2, RoundingMode.HALF_UP);;
    }
}

4.3 简单工厂模式

甚至更近一步，根据开闭原则，我们将获取ICalculator的逻辑委托给工厂，让service进一步做到计算逻辑的无感，甚至无需自己对计算方法进行选择。


public class CalculatorFactory {

    public static ICalculator calculate(String type) {
        if (type.equals("sercviceFee")) {
            return new ServiceFeeCalculator();
        } else if (type.equals("salalry")) {
            return new SalaryCalculator();
        } else if ()......省略
    }
}

当然上述的工厂模式可以进一步的优化，有兴趣的可以看我之前的一篇文章

使用工厂、模板、策略模式重构代码

最终在service使用的时候效果

public void distributeTask(Request request) {
        。。。

        //任务实体
        Task task = generateTask(request);
        //计算服务费（此处可以将简单工厂模式进一步的优化）
        **BigDecimal serviceFee = CalculatorFactory.calculate("serviceFee").calcualate(task);**
        。。。。
        //保存任务
        save(task);
        。。。。
    }