可能违反单一职责原则的控制器？

Question

参考此评论，

当一个类有很长的参数列表时，它可以是一个“代码 闻到“你的班级试图做的太多而且可能没有 遵循单一责任原则。如果你的班级正在尝试 做太多，考虑将你的代码重构为一些 相互消耗的小类。

我应该如何处理下面的这个控制器类 - 它是“试图做太多”吗？

class Controller
{
    public $template;
    public $translation;
    public $auth;
    public $article;
    public $nav;

    public function __construct(Database $connection, $template) 
    {
        $this->template = $template;
        $this->translation = new Translator($connection);
        $this->nav = new Nav($connection);
        $this->article = new Article($connection);
        $this->auth = new Auth($connection);
    }

    public function getHtml() 
    {
        if(isset($_REQUEST['url'])) 
        {
            $item = $this->article->getRow(['url' => 'home','is_admin' => $this->auth->is_admin]);
            include $this->template->path;
        }
    }
}

我如何将它分解为更小的类 - 如果它是一个控制器，它包含我需要输出页面的这些基本类？

我应该怎么做才能遵循dependency injection的原则？

Answer 1

_{注意：这将是简短的版本，因为我在工作。晚上我会详细说明}

所以...您的代码有以下违规行为：

• SRP（以及扩展 - SoC）：您的控制器负责验证输入、授权、数据收集、用数据填充模板并呈现所述模板。此外，您的Article 似乎同时负责数据库抽象和域逻辑。

• LoD：您正在传递$connection，因为您需要将它传递给其他结构。

• 封装：您的所有类属性都具有公开可见性，并且可以随时更改。

• 依赖注入：虽然你的“控制器”有几个直接依赖，但你只是传入了模板（实际上不应该由适当的 MVC 中的控制器管理）。

• 全局状态：你的代码依赖于$_REQUEST superglobal。

• 松散耦合：您的代码直接与类的名称以及您在构造函数中初始化的这些类的构造函数的足迹相关联。

Answer 2

TL;DR：我在这里没有看到违反 SRP，但对象组合略有损坏

据我所见（这是完整的类列表吗？），$connection 没有直接在类中使用，因此不应注入。

而且我在任何地方都看不到$this->translation 和$this->nav 的用法。那是复制粘贴的神器吗？

宁可注入$connection，我会在这个类之外构造Article和Auth，然后只注入这些，因为你的控制器只直接使用这些，而不是控制器。 所以整个班级会是这样的：

class Controller
{
    private $article;
    private $auth;
    private $template;

    public function __construct(Article $article, Auth $auth, $template) 
    {
        $this->article = $article;
        $this->auth = $auth;
        $this->template = $template;
    }

    public function getHtml() 
    {
        if(isset($_REQUEST['url'])) 
        {
            $item = $this->article->getRow(['url' => 'home','is_admin' => $this->auth->is_admin]);
            include $this->template->path;
        }
    }
}

除非您的Article 是具有ActiveRecord 模式的域对象，否则我仍然会注入$connection 并将其存储在局部变量中。并且仅在您真正需要它时创建新的Article 对象，即在getHtml 方法中。

这样你就不用在构造函数中做太多的工作，只分配局部变量。对象组合在其他地方处理。如果需要，您可以替换 Auth 的实现。

此外，当您不在构造函数中做太多工作时，您的对象图创建非常便宜。如果您使用某种 DI 容器，当必须同时创建大量对象时，这一点很重要。