oop - 使用构造函数依赖注入(inject)时提供依赖项的后备/默认值？

Question

使用依赖注入(inject)时这是否不好:

public function __construct($service = null)
{
    if(null === $service){
        $service = MyNewDefaultService()
    }
    $this->service = $service;
}

即服务有默认后备类类型的概念

Answer 1

此模式可行(事实上，(反)模式有 name - Bastard Injection )，但存在与此方法相关的问题:

1. 通过在使用者类中构造新的 MyNewDefaultService() 依赖项，除了抽象之外，您还可以耦合到具体的服务类。在编译语言中，这也意味着您使用的代码现在需要对包含具体依赖类的 jar/库/dll/程序集进行硬“引用”，而如果您省略直接构造，则可以仅在接口(interface)上耦合。在脚本语言中，您需要确保具体的依赖关系在运行时是可解析的。

2. 依赖项 MyNewDefaultService 的生命周期管理现在已硬编码为与消费类的生命周期相同。由 IoC 容器注入(inject)和管理的对象的生命周期可以为您提供比这更大的灵 active (例如注入(inject)共享对象等)。

3. 测试现在更加复杂，因为您无法模拟“默认”路径(即当 $service == null 时)，因此您需要混合使用单元测试(对于注入(inject)的路径，带有模拟的依赖项)和集成测试(对于默认路径)来证明代码的正确性。

4. 如果您的依赖项本身具有其他依赖项，这些依赖项也使用构造函数注入(inject)，则默认构造路径很快就会变得笨拙，并导致更多的耦合，因为您现在需要完成所有艰苦的工作来解决 IoC 所依赖的依赖项容器就可以为您完成，例如

if(null === $service){
    $service = MyNewDefaultService(RepoFactory.Create(LoggerFactory.Create()), ...)
}

TL;DR 虽然这种方法在从耦合层次结构迁移到由 IoC 容器管理的松散耦合依赖注入(inject)层次结构的过渡阶段可能很有用，但这种方法的真正好处是Dependency Inversion Principle只有当构造函数只有一条路径时，即通过将抽象耦合到所有依赖项，而不是任何具体实现，才能完全实现。