依赖注入只用于测试？

Question

我多次读到硬编码对象不是一个好的实践：

class Session
{
    private $user;

    function __construct()
    {
        $this->user = new User();
    }
}

它的坏仅仅是因为它的不可测试的行为？我只是觉得这种硬编码更容易阅读。当然，我可以添加那些类似DI的方法：

    public function setUser (User $userObj)
    {
        $this->user = $userObj;
    }

    public function getUser()
    {
        return $this->user;
    }

但这就像一座房子，即使是桁架也可以被改变。干什么用?For what？

Answer 1

不像房子，它是一个有形的物体，在那里的桁架是不能改变的，这是代码，其中的东西不是永久的。

老实说，我已经使用DI多年了，我认为它被过度使用了。非常简单:一组类的依赖项不会改变，如果它们改变了，那么很容易将DI应用于它们。

坚持房子的类比，我的立场是“现在不一定要建造整个房屋扩建，但也不要建造一个承载墙，在那里的门可能需要去”。我会在构造函数中创建依赖对象，因此，如果有必要使其可交换，那么很容易添加构造函数arg，并在需要时通过DI框架开始传递依赖项。

有一件事情是你自己没有做好的，那就是创建这个类的每个实例都需要用一个DI友好的版本来代替，这意味着要进行大量的重构，因此需要进行大量的回归测试。这是一个很大的风险。如果您确保获得了非常彻底的自动化测试覆盖率，那么这种风险就会大大减轻。

另一方面..。从一开始就使用DI框架，即使没有立即注入依赖项，当需要注入依赖项时，它仍然会进一步减轻这种考虑。

使用DI确实使您的测试更加容易，这反过来将提高您获得更高测试覆盖率的能力。但我也不认为应该专门为测试编写代码。

所以，在做出这个决定时，有几件事情需要权衡，并适用于你的具体风格和要求。