如果我使用依赖注入模式来删除依赖项,那么它们会在其他地方结束。
例如,Snippet 1或我称之为Object Maker。
我的意思是你必须在某处实例化你的对象......所以当你从一个对象中移出依赖项时,你最终会把它放到另一个对象中。
我看到这会将我的所有依赖项整合到一个对象中。这是重点,减少你的依赖关系,使它们都位于一个(尽可能接近)的位置?
代码段1 - 对象制作工具
<?php
class ObjectMaker
{
public function makeSignUp()
{
$DatabaseObject = new Database();
$TextObject = new Text();
$MessageObject = new Message();
$SignUpObject = new ControlSignUp();
$SignUpObject->setObjects($DatabaseObject, $TextObject, $MessageObject);
return $SignUpObject;
}
public function makeSignIn()
{
$DatabaseObject = new Database();
$TextObject = new Text();
$MessageObject = new Message();
$SignInObject = new ControlSignIn();
$SignInObject->setObjects($DatabaseObject, $TextObject, $MessageObject);
return $SignInObject;
}
public function makeTweet( $DatabaseObject = NULL, $TextObject = NULL, $MessageObject = NULL )
{
if( $DatabaseObject == 'small' )
{
$DatabaseObject = new Database();
}
else if( $DatabaseObject == NULL )
{
$DatabaseObject = new Database();
$TextObject = new Text();
$MessageObject = new Message();
}
$TweetObject = new ControlTweet();
$TweetObject->setObjects($DatabaseObject, $TextObject, $MessageObject);
return $TweetObject;
}
public function makeBookmark( $DatabaseObject = NULL, $TextObject = NULL, $MessageObject = NULL )
{
if( $DatabaseObject == 'small' )
{
$DatabaseObject = new Database();
}
else if( $DatabaseObject == NULL )
{
$DatabaseObject = new Database();
$TextObject = new Text();
$MessageObject = new Message();
}
$BookmarkObject = new ControlBookmark();
$BookmarkObject->setObjects($DatabaseObject,$TextObject,$MessageObject);
return $BookmarkObject;
}
}
答案 0 :(得分:2)
我个人而言,宁愿将对象实例化到任何有意义的实例化它们,并在特殊的文档文件中很好地记录依赖项。
答案 1 :(得分:2)
不,它与合并您的依赖项无关。它与使对象更易于测试有关。
是的,副作用是你的依赖关系倾向于出现在其他地方,但重点是依赖关系不在你正在测试的对象中。
如果不在目标对象中创建依赖项,则可以实例化测试(或伪造或模拟)对象以提供给目标对象。如果对象创建了自己的依赖项,那么这是不可能的。
这样想。假设你有一个Car对象。如果汽车创建了驱动程序,那么其他驱动程序就无法驱动它。它只能是All Foo Car,因为你有一个硬编码的驱动程序创建。
现在,假设我们开发了一款机器人,用于在特别设计的赛道上测试赛车。同样,我们无法将机器人放在驾驶员座椅上,因为你会在那里进行硬编码。
当然,可测试性只是依赖注入的一个好处,依赖项的强制解耦意味着您必须编写更多的模块化代码。如果您正在使用依赖注入框架(Crafty或类似),那么您可以根据需要使依赖项自动实例化,这有很多好处,但这对于使用更强大的类型语言更有利。
答案 2 :(得分:1)
请问自己,“这属于一起吗?”
如果某事物是你对象的“一部分”,则可能是“是”。如果某事是“属性”,那么是。
我能提供的最佳指南是什么?从PHP手册:
http://www.php.net/manual/en/language.oop5.basic.php
PHP类可以用于几个方面,但最基本的 等级,你将使用类来“组织和处理志同道合的 数据”。
PS: 创建一个首先需要它的对象。
PPS: “将我的所有依赖项合并到一个对象中”......如果你聚在一起的对象不一定有任何直接相关的东西......可能是你能做的最糟糕的事情。 IMHO ...
答案 3 :(得分:1)
重点是减少你的依赖关系以便它们都位于一个(尽可能接近的)位置吗?
我认为基本上就是这样,是的。我们的想法是使应用程序的组件松散耦合。这意味着您可以更轻松地重用组件,交换组件并对其进行测试。如果你有一个简单的应用程序,当然它可以很好地实例化需要它们的对象。但随着它变得越来越复杂,具有多个嵌套依赖项,您的代码可能会紧密耦合,这意味着难以维护,调整和测试。
答案 4 :(得分:0)
在传统的软件开发中,依赖对象自己决定它将使用哪些具体类。在依赖注入模式中,此决策被委托给“注入器”,它可以选择在运行时而不是在编译时替换依赖项契约接口的不同具体类实现。
DI导致某些类与不稳定类的耦合较少。注入的实例通常是接口的实现。 OCP告诉我们实现中的更改不应该要求修改依赖于它们的封闭类。
tl; dr A类仅依赖于注入的接口I的实现更具凝聚力(责任更少)。其他一些课程则受到选择,实例化等的责任,但该课程也更具凝聚力。