大量构建一种实现。DI无望吗？使用服务定位器？
假设我们有1001个客户端，它们直接构造其依赖关系，而不接受注入。根据我们的老板，重构1001不是一个选择。实际上，甚至不允许我们访问其源代码，而只能访问类文件。 我们应该做的是“现代化”这1001个客户所经历的系统。我们可以重构自己喜欢的一切。依赖关系是该系统的一部分。还有一些依赖关系我们应该更改为具有新的实现。 我们想要做的是能够配置依赖关系的不同实现，以满足众多客户的需求。可悲的是，DI似乎不是一个选择，因为客户端不接受构造函数或setter的注入。 选项： 1）重构客户端使用的服务的实现，以使其执行客户端现在需要的功能。砰，我们完成了。不灵活。不复杂。 2）重构实现，以便将其工作委托给它通过工厂获取的另一个依赖项。现在，我们可以通过重构工厂来控制它们都使用哪种实现。 3）重构实现，以便将其工作委托给它通过服务定位器获取的另一个依赖项。现在，我们可以通过配置服务定位器来控制它们都使用哪种实现，该服务定位器可能只是hashmap对象的字符串，并且需要进行一些强制转换。 4）我什至没有想到的东西。 目标： 在不增加毫无意义的复杂性的情况下，将因设计欠佳的旧客户端代码拖到将来而导致的设计损失最小化。 客户不应该了解或控制其依赖项的实现，但是他们坚持使用来构建它们new。我们无法控制，new但可以控制他们正在构建的类。 我的问题： 我没有考虑什么？ Doc Brown的问题 您是否真的需要在不同的实现之间进行配置？出于什么目的？ 敏捷。很多未知数。管理层希望变革的潜力。只失去对外界的依赖。还测试。 您是否需要运行时机制或只是编译时机制来在不同的实现之间进行切换？为什么？ 编译时间机制可能就足够了。除测试外。 您需要在实现之间切换哪种粒度？一次全部？每个模块（每个模块包含一组类）？每堂课？ 在1001中，任何一次都只能运行一次。一次更改所有客户端使用的内容可能很好。但是，对依赖项的单独控制可能很重要。 谁需要控制开关？只有您/您的开发人员团队？管理员？每个客户自己吗？还是客户的代码的维护开发人员？那么，机械师需要多么容易/稳健/万无一失？ 开发测试。管理员随着外部硬件依赖性的变化而变化。它需要易于测试和配置。 我们的目标是证明该系统可以快速重建和现代化。 实施开关的实际用例？ 一种是，在硬件解决方案准备就绪之前，一些数据将由软件提供。