Question

我在考虑单一责任原则，我提出了这个问题。让我们说一个班需要由另一个人注入。将第二个类作为参数发送到第一个构造函数中是否更好，或者只将它包含在第一个构造函数中？

为了解释我的问题，我写了这个小代码。在第一个代码中，A需要B并在其构造函数中创建B的对象。

require_once('classb.php');

class A {

    protected $b;

    public function __construct(){
        $this->b = new B;
    }
}

在第二个代码中，A将B作为参数并将其分配给构造函数中的内部变量$。

class A {

    protected $b;

    public function __construct(B $b){

        $this->b = $b;
    }

}

我知道使用第二种方式的一个好处，如果A在某些情况下也需要得到C;而不是将类本身发送到A的构造函数，接口将像需要完成的类的引用一样。

另一方面，如果我们确定A中只有一个课程，那么使用第一个课程可以节省我们每次初始化B的时间和行。

问题是，如果像第一种方式那样干扰任何最佳实践原则或有一些不利方面？

Answer 1

如果您有疑问，可以制作 public function __construct(B $b = null){ if (isset($b)) $this->b = $b; else $this->b = new B; }

Answer 2

这取决于实际使用的A和B。如果B只是A类用户不需要了解的实现细节，请使用方法1.如果实现发生变化（可能更改C类的B类甚至使B过时），则A类不需要改变他的代码。

如果A类用户需要了解B（可能B是一个界面，并且有多种选择），请使用方法2.

Answer 3

我会使用方法二进行一些修改 - 课程

而不是使用类提示类型，请使用interface（例如abInterface）。为什么？因为它允许你注入abInterface的任何具体实现

program to an interface not implmenation

假设A类是一个服务，假设您有应用程序类或index.php文件创建服务A对象，如果您允许应用程序在创建服务A对象时传递对象B，那么您是基本上允许应用程序选择任何类（它可以通过abInterface的任何实现）。如果你这样做，你的服务将是开放的扩展但关闭修改（你不必修改类A的构造函数）如果你想注入例如class C而不是class B

open close principle

您还可以使用dependency注入容器来连接所有对象，这样您就不必担心管理依赖项我并不是说您需要DI容器这个特殊情况但如果你想这样做，你只能采用方法二

在另一个类中创建一个对象＆＃39;构造函数扰乱任何原则？

3 个答案: