Java开发中如何避免向Entity子类向下传递依赖？

你提到的直接用单例静态获取的方案确实会产生强耦合的上帝依赖问题：Entity会和服务的实例化逻辑硬绑定，无法在单元测试时mock依赖，后续如果需要多套服务实现（比如分场景用不同的药水服务逻辑）也完全无法扩展，不推荐使用。

以下是三种适配不同场景的可落地解决方案： #

方案1：实体工厂模式（优先推荐） #

这是最符合依赖倒置原则、无额外框架依赖的解决方案，核心思路是把所有实体的实例化逻辑收敛到统一的工厂类中，父类所需的公共依赖仅需注入给工厂一次，创建子类实例时由工厂自动补全父级依赖，上层调用方完全不需要感知父类依赖的存在。
示例代码：

// 实体工厂，仅需初始化一次，统一持有父级公共依赖
public class EntityFactory {
    private final EntityTypeConverter converter;
    private final AbstractPotionService potionService;

    // 公共依赖仅在工厂初始化时传入一次
    public EntityFactory(EntityTypeConverter converter, AbstractPotionService potionService) {
        this.converter = converter;
        this.potionService = potionService;
    }

    // 创建MobileEntity实例，调用方无需传递父类依赖
    public MobileEntity createMobileEntity() {
        return new MobileEntity(converter, potionService);
    }

    // 新增其他Entity子类时，仅需在此处添加对应创建方法
    public StaticEntity createStaticEntity(int hp) {
        return new StaticEntity(converter, potionService, hp);
    }
}

优势：

• 后续扩展Entity父类新增依赖时，仅需修改工厂构造和Entity父类构造，所有子类实例化的上层代码无需调整，可维护性极高
• 无硬编码依赖，所有服务实现都可以自定义替换，单元测试时可以轻松mock依赖
• 完全不需要引入额外框架，适配所有Java项目场景

方案2：DI框架字段注入（适配已有Spring/Guice生态的项目） #

如果你的项目已经使用了Spring、Guice这类依赖注入框架，可以通过@Configurable+字节码编织的能力，让框架自动给你手动new出来的Entity实例注入依赖，不需要手动传递构造参数。
示例代码：

@Configurable // 开启非容器管理对象的注入能力
public class Entity {
    @Autowired
    private AbstractPotionService potionService;
    @Autowired
    protected EntityTypeConverter converter;

    public Entity() {}

    // 原有业务逻辑保持不变
    public void addEffect(EffectType effectType, int durationInSeconds) {
        potionService.applyEffectTo(this, effectType, durationInSeconds);
    }
}

// 子类无需再声明父类依赖的构造参数
public class MobileEntity extends Entity {
    public MobileEntity() {
        super();
    }

    // 原有业务逻辑保持不变
    public void attack(MobileEntity victim) {
        // ...
    }
}

优势：代码改动量最小，上层实例化逻辑完全不需要调整，仅需给父类加注入注解即可。

方案3：服务定位器模式（适配旧项目低改造成本场景） #

如果是旧项目，上层实例化实体的逻辑分散在多处，改造成工厂模式成本过高，可以用服务定位器模式替代硬编码单例，比直接用单例灵活度更高。
示例代码：

// 服务定位器，全局统一管理公共依赖
public class ServiceLocator {
    private static ServiceLocator INSTANCE;
    private final AbstractPotionService potionService;
    private final EntityTypeConverter converter;

    // 项目启动时统一初始化依赖
    public static void init(EntityTypeConverter converter, AbstractPotionService potionService) {
        INSTANCE = new ServiceLocator(converter, potionService);
    }

    private ServiceLocator(EntityTypeConverter converter, AbstractPotionService potionService) {
        this.converter = converter;
        this.potionService = potionService;
    }

    public static AbstractPotionService getPotionService() {
        return INSTANCE.potionService;
    }

    public static EntityTypeConverter getConverter() {
        return INSTANCE.converter;
    }
}

// 父类直接从定位器获取依赖
public class Entity {
    private AbstractPotionService potionService;
    protected EntityTypeConverter converter;

    public Entity() {
        this.converter = ServiceLocator.getConverter();
        this.potionService = ServiceLocator.getPotionService();
    }

    // 原有业务逻辑不变
}

优势：上层实例化代码几乎不需要改动，改造成本极低，比硬编码单例更容易扩展和测试。

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