我在确定正确的方法或编写模块时遇到问题。我认为我知道依赖注入背后的理论以及它的优点是什么,但也许我正在混合某些东西或者没有非常清晰的图像。
一个相当简化的例子是:
我有一个我的对象的模型,在这里我注入一个验证器类来处理各种验证:
// index.php
// ......
$model = new Model();
$model->setValidator(new Validator());
$model->getValidator()->exampleValidateCall();
// ......
// validator.php
class Validator implements ValidatorInterface {
//.....
public function exampleValidateCall() {
// code goes here
}
}
我的问题在于我需要访问设置实体,以定义模型的行为。因为设置定义了模型,所以我认为我不应该在验证器中传递theese设置。
一个选项是验证器将扩展模型,但我认为这将是不好的做法(因为整个依赖注入概念变为kaboom ......或者不是?)。我可以做类似的事情:
$model->setValidator(new Validator($model->getSettings()));
但从我的观点来看,这看起来更加愚蠢。
从我的观点来看,一个更好的解决方案是将新对象传递给验证器构造函数
$model->setValidator(new Validator(new Settings()));
因为实际上设置不依赖于模型,但这似乎有点复杂。而且设置实体也是在模型中构建的,因为它违反了一些行为。
编写这些对象/依赖项的最佳做法是什么?
答案 0 :(得分:3)
This would not fit in a comment, so I'm posting as an answer.
$model->setValidator(new Validator($model->getSettings()));
but this looks even more idiotic from my point of view.
This is not idiotic whatsoever. It is a completely valid construction and even respectful to the Law of Demeter.
The main question here is whether it makes sense to store your settings within your model or it should be a separete a different object as you pointed:
$model->setValidator(new Validator(new Settings()));
If you're building a generic validator with which you can parametrize business rules, I think it's valid to have theese settings lying in your model.
Otherwise, If this validation is entity-specific, I think this would be better as a different structure.
答案 1 :(得分:0)
DI的经验法则是,如果Validator
需要Settings
进行操作,那么它应该传递给构造函数。如果它可以在没有设置的情况下运行,那么您可以使用添加依赖关系后实例化。您的另一种选择可能是将其传递给将在其中使用的方法。
$model->setValidator(new Validator());
$model->validator($thingToValidate, $model->getValidationSettings());