设置器、验证器和依赖注入答案

【问题标题】：setter, validator and dependency injection设置器、验证器和依赖注入
【发布时间】：2012-05-21 17:41:57
【问题描述】：

假设我有一个 Thing 类，我需要使用由扩展 Zend_Validate_Abstract 的 MySpecificDateValidation 类提供的一些特定日期验证。

在 Thing 类中，我正在考虑依赖注入，想知道这段代码是否：

public function SetDateBegin($dateBegin) {
    $dateValidator = new MySpecificDateValidation();
    if ($dateValidator->isValid($dateBegin)) {
        $this->dateBegin = $dateBegin;
    } else {
        throw new Exception /*...*/;
    }
}

应该重构为：

public function SetDateBegin($dateBegin, MySpecificDateValidation $dateValidator) {
    if ($dateValidator->isValid($dateBegin)) {
        $this->dateBegin = $dateBegin;
    } else {
        throw new Exception /*...*/;
    }
}

或者有一些你可以忍受的依赖？

【问题讨论】：

在创建时将验证器传递给对象而不是每个函数可能会更好。如果从不调用 SetDateBegin，除非你有充分的理由避免额外的包袱，否则需要扔掉的代码会少很多。
但是，另一方面，如果我有十几个属性和六个不同的验证器，这（传递创建）会给构造函数带来额外的权重，不是吗？
@RodrigoAoCubo 如果你的类有这么多需要重构的依赖项，那么它做的太多了！话虽如此，您将依赖项传递到何处取决于您的用例。
也许我有点“夸张”了，或者在我描述它的方式上造成了混淆......我不是在谈论一种方法中的 12 个参数，同时有 6 个不同的验证器，而是类有大约 12 个 setter 和一种不同的验证器，对所有的验证器都不一样。它会变得不那么讨厌吗？ :)
大声笑，有点不那么讨厌，但不多:)

标签： php oop validation dependency-injection setter

【解决方案1】：

您的第二个选项对于unit test 会容易得多，因为您将能够模拟验证器并注入mocked object 而不是真实的。

如果您尝试对第一个选项进行单元测试，您最终会测试 Thing 类以及它所依赖的任何内容，例如验证器。如果单元测试失败，则必须通过所有依赖项跟踪失败。

dependency injection 的意义在于允许您将您的类与其依赖项隔离开来，以便您单独测试每个类。

因此，从测试的角度来看，您应该始终注入所有依赖项。

【讨论】：

好的，我知道它（单元测试）是主要的好处。我相信我仍在努力适应这个想法并抛弃旧的坏习惯......
@RodrigoAoCubo 单元测试不是主要的好处，它本质上是唯一的好处。其他所有事情都可以通过其他方式更有效地完成，但只有通过 DI，您才能相对轻松地完成所有这些事情，并且仍然可以轻松地进行单元测试。