Java 接口的所有子类都需要执行相同处理逻辑的推荐姿势

Java 接口的所有子类都需要执行相同处理逻辑的推荐姿势 一、背景

在实际开发过程中，有些时候我们可能会遇到这样的场景：我们定义接口给上游使用，不同的业务类型定义不同的子类型，实现该接口的某个函数，但是这些子类型会有很多公共的逻辑（公共的步骤）。

如果将这部分代码定义为工具方法，就需要在每个子类中都执行对应的调用。

如果有些公共步骤的返回值和接口中定义的返回值一致时，很容易出现漏调用的情况。

那么，该如何 “强制”子类型都要执行一些相同的步骤呢？

二、描述

下面都是伪代码，大家不必纠结于具体细节，理解意思即可。

我们需要提供给上游这样一个接口， type 是指当前服务能够处理的类型，something 代表实际执行的业务功能。

public interface SomeInterface {

    String type();
    
    ResultDTO something(Param param);
}

第一个实现类：

public class AImpl implements SomeInterface {

	@Override
    public String type() {
        return "A";
    }
    
    @Override
    public ResultDTO something(Param param) {
        // 特有逻辑
        ResultDTO resultDTO = buildPart(param);

        // 构造公共逻辑所需的参数
        OtherParam otherParam = new OtherParam();

        // 公有逻辑
        return SomeUtils.fillCommon(resultDTO, otherParam);
    }

    private ResultDTO buildPart(Param param) {
        ResultDTO result = new ResultDTO();
        // 执行查询

        // 塞入特有属性

        return result;
    }
}

第二个实现类：

public class BImpl implements SomeInterface {

	@Override
    public String type() {
        return "B";
    }
    
    @Override
    public ResultDTO something(Param param) {
        // 特有逻辑
        ResultDTO resultDTO = buildPart(param);

        // 构造公共逻辑所需的参数
        OtherParam otherParam = new OtherParam();

        // 公有逻辑
        return SomeUtils.fillCommon(resultDTO, otherParam);
    }

    private ResultDTO buildPart(Param param) {
        ResultDTO result = new ResultDTO();
        // 执行查询

        // 塞入特有属性

        return result;
    }

}

使用时，构造 Map type2BeanMap ，然后根据当前的 type 去执行具体的实现 Bean。

具体可参考《巧用 Spring 自动注入实现策略模式升级版》

问题：如果我们新增 CImpl 继承 SomeInterface 就必须查看 AImpl 或者 BImpl 源码才知道有一段公共逻辑，很容易遗漏这一段公共逻辑。

如果我们想让新建子类时，不需要担心遗漏这段公共的逻辑，该怎么办？

三、方案

如果大家对设计模式比较熟悉的话，这种场景我们很自然地会联想到模板模式。

我们将采用这种设计模式，对代码进行改造。

（1）我们将特有逻辑上提到接口中，在 default 方法中编排逻辑即可。

public interface SomeInterface {

    String type();

    // 目标方法
    default ResultDTO something(Param param) {
        return SomeUtils.fillCommon(buildPart(param));
    }

    
    MiddleParam buildPart(Param param);
}

定义为接口的好处是，不会影响到子类继承其他父类型（Java 是单继承机制）。

（2）可以将 SomeInterface 改为抽象类（AbstractSomeService），something定义为 public ,将 builPart 定义为抽象函数，让子类去重写。

public abstract class AbstractSomeService {

    abstract String type();

    // 目标方法
    public ResultDTO something(Param param) {
        return SomeUtils.fillCommon(buildPart(param));
    }

    
    abstract MiddleParam buildPart(Param param);
}

定义为抽象类的坏处是子类型无法再继承其他类，但理论上也不应该(不需要) 再继承其他类，好处是可以将buildPart 重写的访问修饰符范围降低，如改为 protected。

注意：
(1) 本案例里的 SomeUtils.fillCommon 只是伪代码，公共逻辑可能封装在工具类中，也可能封装在某个 bean 中，在抽象类或者接口中可以通过ApplicationContextHolder 去获取并调用。
(2) 实际编码时，公共逻辑也未必在最后调用。
(3) 实际编码中，公共的步骤可能不止一个，但是方案是一致的，有几个定义几个抽象方法即可。
(4)实际编码时，公共的步骤可能不需要返回值

定义中间参数：

@Data
public class MiddleParam {

    private ResultDTO semiResult;

    private OtherParam otherParam;
}

第一个实现类：

public class AImpl extends AbstractSomeService {
    @Override
    public String type() {
        return "A";
    }


    @Override
    protected  MiddleParam buildPart(Param param) {
        MiddleParam middleParam = new MiddleParam();
        // 执行查询

        // 塞入特有属性

        return middleParam;
    }
}

第二个实现类：

public class BImpl extends AbstractSomeService {

    @Override
    public String type() {
        return "B";
    }

    @Override
    protected  MiddleParam buildPart(Param param) {
        MiddleParam middleParam = new MiddleParam();
        // 执行查询

        // 塞入特有属性

        return middleParam;
    }

}

这样通过类似 buildPart 这种函数名，可以明确感知到当前是对部分逻辑进行处理，且不需要在当前子类中执行公共逻辑的调用。

四、总结

本文案例比较简单，主要思想是使用模板模式来实现公共步骤的编排。

希望大家遇到类似场景时，可以使用更优雅的方式，更健壮的方式去实现，而不是依靠“口口相传” 或者让别人看你代码才知道该怎么写。

---

创作不易，如果本文对你有帮助，欢迎点赞、收藏加关注，你的支持和鼓励，是我创作的最大动力。