setter,验证器和依赖注入

比方说,我有一个Thing类,并且需要使用MySpecificDateValidation类提供的特定日期验证来扩展Zend_Validate_Abstract。

在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 /*...*/;
    }
}

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

2
额外 编辑
意见: 1
但是,另一方面,如果我有十几个有六种不同验证器的属性,这(通过创建)会给构造器带来额外的重量,不是吗?
额外 作者 Rodrigo Além Disso,
也许我已经“夸张”了一下,或者用我描述过的方式混淆了......我并不是用一种方法用6种不同的验证器在一起讨论12个参数,而是一个有大约12个setter的类不同的验证器,不一样。它是否会变得不那么讨厌? :)
额外 作者 Rodrigo Além Disso,
@RodrigoAoCubo如果你的类有很多依赖需要重新分解,那么它太多了!话虽如此,你传递依赖的地方取决于你的用例。
额外 作者 vascowhite,
大声笑,少一点讨厌,但不多:)
额外 作者 vascowhite,
可能更好地将验证器传递到创建对象上,而不是传递到每个函数中。除非你有一个令人信服的理由来避免额外的行李,否则如果SetDateBegin从不被调用,代码会少得多。
额外 作者 DampeS8N,

1 答案

您的第二个选项将更容易单元测试,因为您将能够模拟验证程序并注入而不是真实的嘲弄对象

如果你尝试单元测试第一个选项,你最终将测试Thing类加上它所依赖的任何东西,比如验证器。如果单元测试失败,则必须通过所有依赖关系来跟踪失败。

依赖注入的目的是让您将您的类与它们的依赖关系隔离开来,以便测试每个类处于隔离状态。

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

4
额外
好吧,我明白它(单元测试)是主要的好处。我相信我仍然在努力习惯这个想法,并且留下旧的坏习惯......
额外 作者 Rodrigo Além Disso,
@RodrigoAoCubo单元测试不是主要的好处,它本质上是唯一的好处。其他任何事情都可以通过其他方式更高效地完成,但只有通过DI才能完成所有这些事情,并且还可以轻松进行单元测试。
额外 作者 DampeS8N,