OOP依赖关系:依赖注入与注册表

Question

我知道一些OOP并且已经读过这个和那个,但是我不是一个硬核OOP人并且没有正式的训练并且无法解释为什么某些东西应该使用依赖注入,并且可能无法识别设计中的所有依赖项因此我的问题.

在这里回答一个问题(在其他对象的方法中使用对象)我开始怀疑自己.就依赖性而言,其中一种更好还是更差,还是两者都可以接受？任何设计限制？

我已阅读并理解两者,但从未遇到过比较.为什么在设计中更好地使用它等等.

依赖注入:

class myClass {
    private $db;

    public function __construct($db) {
        $this->db = $db;
    }
}

注册表(也许还有别的):

class myClass {
    private $db;

    public function __construct() {
        $this->db = Registry::get('db');
    }
}

Answer 1

它与可测试性有很大关系.

在您的示例中,第一个(依赖注入)更好.它更好的原因是因为它接受db作为参数,这意味着它是可测试的,你可以使用模拟db进行测试,测试myClass是否正确.

第二个例子(注册表)不推荐,因为它不仅myClass取决于db,它现在也取决于Registry,而最糟糕的是它知道如何得到一个db.它太聪明了,它应该像第一个一样愚蠢,愚蠢的东西更容易测试,聪明的东西不是.

Answer 2

两种方法都是依赖注入的可能实现.基本上,依赖注入意味着定义一种配置(注入)要在运行时使用的类的方法,以便与在代码中使用硬编码类名和构造函数相比,使代码更灵活.依赖注入遵循一个叫做的原则inversion of control.

这对于测试代码尤其有用,但可以用于您希望使应用程序灵活和可维护的各种其他场景中.

虽然依赖注入主要被称为DI container,但通常可以使用几种不同的方法来完成 - 这些方法也可以共存.这是一个(不完整的)列表: