如何优化继承抽象实体类的多子类Repository保存逻辑？

你当前通过if-else判断实体类型来选择对应Repository的方式，在子类增多时会导致代码冗余且难以维护，以下是几种可行的优化方案：

方案一：类型映射注册表 #

通过一个Map存储实体类类型与对应Repository的映射关系，直接根据实体类型获取Repository，避免分支判断。

实现代码 #

@Service
public class ShapeService {
    private final Map<Class<? extends ShapeEntity>, JpaRepository<? extends ShapeEntity, String>> shapeRepoMap;

    // 构造注入所有Shape子类的Repository
    public ShapeService(CircleEntityRepository circleRepo, 
                        SquareEntityRepository squareRepo/* 后续新增子类的Repository直接添加到这里 */) {
        shapeRepoMap = new HashMap<>();
        shapeRepoMap.put(CircleEntity.class, circleRepo);
        shapeRepoMap.put(SquareEntity.class, squareRepo);
        // 新增子类时，仅需添加一行put语句即可
    }

    public ShapeEntity save(ShapeEntity shapeEntity) {
        JpaRepository<? extends ShapeEntity, String> targetRepo = shapeRepoMap.get(shapeEntity.getClass());
        if (targetRepo == null) {
            throw new EntityNotFoundException();
        }
        return targetRepo.save(shapeEntity);
    }
}

优点 #

• 类型安全：编译阶段就能发现Repository注入或映射的错误
• 逻辑清晰：新增子类时仅需扩展映射关系，无需修改核心判断逻辑

方案二：利用Spring ApplicationContext自动匹配Repository #

借助Spring的上下文环境，根据实体类名称自动获取对应的Repository Bean，无需手动维护映射表。

实现代码 #

@Service
public class ShapeService {
    private final ApplicationContext applicationContext;

    public ShapeService(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
    }

    public ShapeEntity save(ShapeEntity shapeEntity) {
        // 遵循Repository命名规范：实体类名 + Repository（如CircleEntity对应CircleEntityRepository）
        String repoBeanName = shapeEntity.getClass().getSimpleName() + "Repository";
        try {
            JpaRepository<? extends ShapeEntity, String> targetRepo = 
                applicationContext.getBean(repoBeanName, JpaRepository.class);
            return targetRepo.save(shapeEntity);
        } catch (NoSuchBeanDefinitionException e) {
            throw new EntityNotFoundException();
        }
    }
}

优点 #

• 零配置扩展：新增子类及对应Repository后，无需修改ShapeService代码
• 减少冗余：避免手动维护映射表的重复代码

注意事项 #

• 必须严格遵循Repository的命名约定，否则会出现Bean找不到的异常
• 类型安全性稍弱，错误会在运行时暴露

方案三：泛型Repository（可选） #

如果业务场景允许，可以定义一个泛型Repository接口，结合实体类型的判断来实现通用保存逻辑，但需要处理类型转换：

实现代码 #

首先定义泛型Repository：

public interface ShapeRepository<T extends ShapeEntity> extends JpaRepository<T, String> {
}

然后让所有子类Repository继承该泛型接口：

public interface CircleEntityRepository extends ShapeRepository<CircleEntity> {
}

最后在服务类中通过泛型方式注入并使用：

@Service
public class ShapeService {
    // 注入所有ShapeRepository的实现类
    private final List<ShapeRepository<? extends ShapeEntity>> shapeRepos;

    public ShapeService(List<ShapeRepository<? extends ShapeEntity>> shapeRepos) {
        this.shapeRepos = shapeRepos;
    }

    @SuppressWarnings("unchecked")
    public ShapeEntity save(ShapeEntity shapeEntity) {
        for (ShapeRepository<? extends ShapeEntity> repo : shapeRepos) {
            // 判断Repository的泛型类型是否匹配当前实体
            Type[] genericInterfaces = repo.getClass().getGenericInterfaces();
            for (Type type : genericInterfaces) {
                if (type instanceof ParameterizedType) {
                    ParameterizedType paramType = (ParameterizedType) type;
                    Class<?> entityType = (Class<?>) paramType.getActualTypeArguments()[0];
                    if (entityType.equals(shapeEntity.getClass())) {
                        return ((ShapeRepository<ShapeEntity>) repo).save(shapeEntity);
                    }
                }
            }
        }
        throw new EntityNotFoundException();
    }
}

优点 #

• 完全遵循面向抽象编程的思想
• 新增子类时无需修改服务类代码

缺点 #

• 泛型类型解析逻辑稍复杂，需要处理反射相关代码
• 存在强制类型转换，需要添加@SuppressWarnings注解抑制警告

内容的提问来源于stack exchange，提问作者Lulex97