本文介绍一种通过依赖注入简化服务类获取专属配置的模式，避免在每个服务中重复调用 `configuration.getxxx()`，提升代码内聚性与可测试性。

在典型的分层配置架构中，Configuration 作为顶层聚合对象，封装多个子配置（如 ConfA、ConfB），而各服务（ServiceA、ServiceB）仅需其中一部分。若强制所有服务接收完整 Configuration 对象，不仅违背单一职责原则，还会导致冗余访问逻辑和隐式耦合。

推荐方案：面向配置契约的接口级依赖注入

核心思想是——让每个服务直接声明其真正需要的配置类型，而非整个 Configuration。这可通过重构 Service 接口实现：

// 原始泛化接口（不推荐）
public interface Service {
    void work(Configuration configuratio
n);
}

应升级为泛型化或专用化接口，例如：

// 方案一：泛型接口（更灵活，支持统一调度）
public interface Service {
    void work(T config);
}

public class ServiceA implements Service {
    @Override
    public void work(ConfA confA) {
        // 直接使用 confA，零胶水代码
        System.out.println("Using A config: " + confA.getHost());
    }
}

public class ServiceB implements Service {
    @Override
    public void work(ConfB confB) {
        System.out.println("Using B config: " + confB.getTimeout());
    }
}

或采用更清晰的专用接口（语义更强，利于 IDE 提示与编译检查）：

public interface ServiceA {
    void execute(ConfA config);
}

public interface ServiceB {
    void execute(ConfB config);
}

配套的启动/协调层负责装配：

public class ConfigurationLoader {
    private final Configuration configuration;

    public ConfigurationLoader(Configuration configuration) {
        this.configuration = configuration;
    }

    public void runAllServices() {
        new ServiceA().execute(configuration.getConfA());
        new ServiceB().execute(configuration.getConfB());
        // 或通过 Spring 等容器自动注入：@Autowired private ServiceA serviceA;
    }
}

✅ 优势总结：

• 消除重复提取逻辑：每个服务不再关心“如何从大配置中找自己那部分”；
• 增强类型安全：编译期即校验配置契约，避免运行时 NullPointerException；
• 提升可测性：单元测试可直接传入模拟配置对象，无需构造完整 Configuration；
• 符合依赖倒置原则（DIP）：服务依赖具体配置契约，而非高层聚合对象。

⚠️ 注意事项：

• 若存在跨服务共享配置字段的场景，建议抽取公共配置基类（如 BaseConf），再由 ConfA/ConfB 继承，保持复用性；
• 在 Spring 等框架中，可结合 @ConfigurationProperties 与 @Bean 方法实现自动绑定与注入，进一步减少样板代码；
• 避免为图方便将 Configuration 强转或反射获取子配置——这会破坏封装性与可维护性。

该模式本质是将“配置解析责任”上移至装配层，使业务服务回归纯粹逻辑表达，是构建高内聚、低耦合配置驱动系统的关键实践。