类拆分后依赖注入过多，是否存在针对性的设计模式？

首先得明确：你拆分单一职责类的方向是完全正确的——职责过多的“上帝类”才是真正的代码异味。但依赖注入数量过多，确实可能是个信号，要么是原类的职责仍有冗余，要么是可以通过设计模式来合并相关依赖，让代码更整洁。

针对依赖过多的场景，有几种和建造者模式思路类似（通过封装减少直接依赖）的方案：

1. 门面模式（Facade Pattern） #

如果你的多个依赖属于同一类功能域（比如多种数据库加载器），可以把它们封装到一个门面类里。原类只需要注入这个门面，而不是每个单独的依赖。

• 举个例子：原本要注入MySQLDataLoader、PostgresDataLoader、MongoDataLoader，现在创建一个MultiDataSourceFacade，内部包含这三个加载器的实例，并对外提供统一的loadDataBySource()方法。原类只需要调用门面的方法，无需直接和每个加载器打交道。

2. 聚合服务类 #

如果某些依赖是为了完成一组相关的业务操作（比如多种计算逻辑），可以把这些操作聚合到一个单独的服务类中。原类只依赖这个聚合服务，而不是每个零散的计算类。

• 比如把OrderCalculator、DiscountCalculator、TaxCalculator合并成OrderPricingService，原类只注入这个服务类，通过它获取最终的定价结果。

3. 工厂模式（Factory Pattern） #

如果你的依赖需要根据不同场景动态获取，或者创建逻辑复杂，可以用工厂来封装依赖的创建过程。原类只依赖工厂类，由工厂根据需求返回对应的依赖实例。

• 比如创建DataLoaderFactory，提供getLoader(String sourceType)方法，返回对应的数据库加载器。原类注入工厂，按需获取所需的加载器，而不是一次性注入所有加载器。

额外的排查建议 #

在套用模式之前，先检查原类是否真的需要所有这些依赖：

• 有没有某些依赖的逻辑，可以转移到其他类中？比如原类是否在做本应由依赖类完成的操作？
• 有没有依赖是可以通过方法参数传递，而不是作为类成员注入的？

总的来说，依赖数量多本身不一定是坏设计，但通过上述模式封装相关依赖，既能保持单一职责原则，又能让代码的依赖关系更清晰。

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