依赖注入结合服务定位器的实现是否优于类内解析依赖？

你提到的两种方案核心区别在于依赖解析的位置：示例里是在调用方（RootClass）用ServiceLocator解析依赖后注入MyClass，而另一种是MyClass自己在内部用ServiceLocator获取依赖、保持初始化器无参数。示例这种方案优势很明显：

• 依赖关系透明：MyClass的初始化器直接写明了需要Service类型的依赖，不管是维护代码还是新接手的人，扫一眼初始化器就知道这个类的依赖是什么，不用去翻类的内部实现找隐藏的依赖。
• 复用与扩展更灵活：如果需要给MyClass替换Service的实现（比如测试用的Mock类，或者业务上的新实现），只需要在创建MyClass的时候传不同的实例就行，完全不用修改MyClass的代码。而如果是MyClass内部解析依赖，换实现就得改类里的代码，违反了开闭原则。
• 单元测试更简单：写测试时可以直接传入Mock的Service实例，单独测试MyClass的业务逻辑，不用去处理ServiceLocator的全局单例状态——全局状态很容易导致测试用例之间互相污染，示例方案完全规避了这个问题。
• 耦合度更低：MyClass只依赖Service这个抽象接口，和ServiceLocator这个全局组件没有绑定关系。而内部解析的方案会让MyClass和ServiceLocator强耦合，一旦ServiceLocator的逻辑变动，MyClass也得跟着调整。

当然示例里的RootClass还是依赖了ServiceLocator，但相比把解析逻辑放在MyClass内部，已经把依赖的控制逻辑上移到了更上层的调用方，整体的代码可维护性和可测试性提升了不少。

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