了解 IoC、DI 和参考方法

Question

我正在学习依赖注入和控制反转，我想我开始理解这是如何工作的：

• 对象不应该关心自己依赖项的创建
• 依赖项应该传递给对象（通过构造函数或 setter 方法）
• DI 容器可以完成创建具有所有所需依赖项的对象的工作

如果这一切都是正确的，我可以不再在我的对象中使用所谓的“引用方法”吗？

这就是我所说的参考方法。假设我有两个针对家庭和家庭成员的模型。我发现创建引用与该模型相关的对象的方法非常有帮助。在下面的示例中，当调用 $family->members() 时，我可以快速访问所有家庭成员。但是，这意味着我的 family 对象正在实例化 family_member 类......这是否违反了 IoC 规则？

如果 family_member 类具有超出 family 类范围的依赖项怎么办？在此输入将非常感激！

<?php

    class family
    {
        public $id;

        public function members()
        {
            // Return an array of family_member objects
        }
    }

    class family_member
    {
        public $family_id;
        public $first_name;
        public $last_name;
        public $age;
    }

Answer 1

免责声明：我只是自己学习 DI。对这个答案持保留态度。

依赖注入只是注入依赖。如果您的面向对象设计导致 Family 对象有责任创建 Member 实例，那么无论如何，让 Family 对象创建Member，因为在这种情况下，Member 不再被视为 Family 的依赖项，而是一个责任。。因此：

class Family
{
    /**
     * Constructor.
     * 
     * Since you have decided in your OO design phase that this
     * object should have the responsibility of creating members,
     * Member is no longer a dependency. MySQLi is, since you need
     * it to get the information to create the member. Inject it.
     *
     */
    public function __construct($id, MySQLi $mysqli)
    {
        $this->id = $id;
        $this->mysqli = $mysqli;
    }

    /**
     * Query the database for members data, instantiates them and
     * return them.
     *
     */
    public function getMembers()
    {
        // Do work using MySQLi
    }
}

但是如果你想一想，Family真的应该有创建Member的责任吗？更好的设计是有另一个对象，例如 FamilyMapper 创建 Family 及其成员。像这样：

class FamilyMapper
{
    /**
     * Constructor.
     * 
     * A better OO design, imho is using the DataMapper pattern.
     * The mapper's responsibility is instantiating Family,
     * which means it's going to have to connect to the database,
     * which makes MySQLi its dependency. So we inject it.
     *
     */
    public function __construct(MySQLi $mysqli)
    {
        $this->mysqli = $mysqli;
    }

    public function findByID($familyID)
    {
        // Query database for family and members data
        // Instantiate and return them
    }

}

class Family
{
    /**
     * Constructor.
     * 
     * Family is an object representing a Family and its members,
     * along with methods that *operate* on the data, so Member
     * in this OO design is a dependency. Inject it.
     *
     */
    public function __construct($id, MemberCollection $members)
    {
        $this->id;
        $this->members;
    }

    public function getMembers()
    {
        return $this->members;
    }
}

使用此模式，您的域对象及其方法（可能包含业务逻辑）将与您的数据访问代码解耦。这就是依赖注入的好处——它迫使你重新思考你的面向对象设计，这样你最终会得到更清晰的代码。

很多人认为使用依赖注入就意味着不使用工厂之类的。 这是错误的！依赖注入只是注入依赖项。您也可以对工厂对象使用依赖项注入，通过将依赖项注入工厂而不是让工厂实例化自己的依赖项。

有用的链接：

1. http://martinfowler.com/articles/injection.html
2. 有人对依赖有一个很好的类比吗注入？
3. 如何解释依赖注入一个 5 岁的孩子？

---

补充

再次强调，对下面的内容持保留态度。

另请注意，依赖注入和依赖注入容器之间存在差异。第一个是注入依赖项的简单概念，而不是让对象自己创建它（这会导致非常高的耦合）。我们从上面的例子中看到了这一点。

后者是处理依赖项注入的框架/库的术语，因此您不必进行手动注入。容器的职责是连接依赖关系，因此您不必做肮脏的工作。这个想法是您定义一个依赖项注入配置，它告诉容器Foo对象有哪些依赖项，以及如何注入它们。容器会读取文档并为您执行注入。这就是 Pimple、SimpleDIC 等 DIC 库所做的事情。

您可以将依赖注入容器与工厂进行比较，因为两者都是创建对象，其唯一职责是创建对象。虽然工厂通常是专门化的（即 FamilyMemberFactory 创建 MemberInterface 的实例），但依赖项注入容器更为通用。有人说使用依赖注入容器可以减轻您对工厂的需求，但您应该记住，这意味着您必须创建和维护依赖注入配置文件，这可能是数千个 XML/PHP 行。

我希望这有帮助。

Answer 2

虽然您可以仅使用依赖注入并一直使用，但在我看来，尝试在设计中找到平衡同时保持其可维护性是一种更明智的方法。

因此，依赖注入和工厂的结合将使您的生活变得更加轻松。

class family {
    protected $_members;

    public function __construct($members = array()) {
        $this->_members = array_filter($members, function($obj){
            return ($obj instanceof family_member);
        });
    }

    public function addMember() {
        $this->_members[] = $member = $this->_createMember();
        return $member;
    }

    protected function _createMember() {
        return new family_member;
    }
}

工厂模式在某种程度上与控制反转和依赖注入兼容。虽然依赖项注入使您的对象免于创建其依赖项，但工厂模式允许它创建依赖项的基本实现。最后，它仍然允许您在需要时覆盖对象依赖项：

class familyExtended extends family {
    protected function _createMember() {
        return new familyExtended_member;
    }
}

这在测试时特别有用：

class familyTestable extends family {
    protected function _createMember() {
        return new family_memberFake;
    }
}

依赖项注入很棒，但它不能解决您所有的设计问题。当然，它们是不可互换的。工厂模式可以做 DI 不能做的事情，反之亦然。

Answer 3

问题在于 DI 背后的整个想法是 Family 不应该知道如何创建特定的 FamilyMember，例如，您应该有一个 IFamilyMember > 它的实现可能会因应用程序的每个模块/层而异。

应该是这样的：

public function GetMembers()
{
    $members = array();

    foreach ( $member in $this->internalMemberList ){
       // get the current implementation of IFamilyMember
       $memberImpl = $diContainer->Resolve("IFamilyMember");

       $memberImpl->Name = $member->Name;
       //.... Not the best example....
    }

    return $members;
}

基本上，一切都归结为组件应该不知道其依赖关系，在您的情况下，Family 依赖于 FamilyMember，所以任何< code>FamilyMember 实现需要从 Family 本身中抽象出来。

对于 PHP 的具体情况，请考虑查看 Symfony，它大量使用了 DI 模式，或者您也可以考虑使用 Symfony 依赖注入框架，它是 Symfony 的一部分，但可以用作一个单独的组件。 Fabien Potencier 还针对此事撰写了一篇不错的文章。

希望我能帮忙！