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;
    }

然而它就像一座甚至可以改变桁架的房子。为什么？

Answer 1

与房屋不同，房屋是一个物理对象，而且不能更改，这就是代码，其中事情不那么永久。

说实话，多年来使用DI我觉得它过度使用了。很简单：一堆类的依赖将不会更改，如果它们更改，那么然后将DI应用于它们就足够了。

坚持用房子比喻，我的立场变得“现在不一定建造整个房屋扩建，但也不建造一扇门可能需要走的承重墙”。我将在构造函数中创建依赖项对象，因此如果有必要使它们可交换，则很容易添加构造函数arg并在需要时通过DI框架开始传递依赖项。

你要为自己打开的一件事是，创建该类的每个实例都需要替换为DI友好版本，这意味着需要进行大量的重构，并进行大量的回归测试。这是一个很大的风险。如果您确保自己拥有非常彻底的自动化测试覆盖率，那么可以减轻很多风险。

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

使用DI肯定可以使您的测试更容易，这反过来会提高您实现更高测试覆盖率的能力。但我也不认为应该将专门用于进行测试。

在做出这个决定时，有一些事情需要权衡并适用于您的特定风格和要求。

依赖注入仅用于测试？

1 个答案: