OOP – 嵌套对象依赖项的长链是反模式吗？

发布时间：2020-12-14 04:52:26 所属栏目：百科来源：网络整理

导读：我正在尝试编写使用依赖注入的代码,既允许进行模拟,又可以使用更清晰,更明确的设计. 我经常发现自己遇到了一个我认为常见的特定问题,但我还没有在网上找到任何帮助我克服它的东西. 问题是对象A依赖于B,B依赖于C,C依赖于D,依此类推,链中可能包含许多链接. 似

我正在尝试编写使用依赖注入的代码,既允许进行模拟,又可以使用更清晰,更明确的设计.

我经常发现自己遇到了一个我认为常见的特定问题,但我还没有在网上找到任何帮助我克服它的东西.

问题是对象A依赖于B,B依赖于C,C依赖于D,依此类推,链中可能包含许多链接.

似乎在这里练习依赖注入,A必须在其构造函数中要求B,C,D等,或者对于创建它们所依赖的实例的对象,要求BFactory,CFactory等.我假设为了论证,依赖关系不是可选的或对特定方法有所依赖,使得setter注入或方法参数注入不合适.

这向我表明,长链的依赖对象是反模式.从抽象的角度来看,它与箭头反模式有一些共同之处.长链的依赖对象形成箭头形的序列图.

那么,也许,我应该避免这种做法,并遵循“禅宗的Python”中的建议,即“扁平比嵌套好”.这表明主程序创建两个或三个对象的设计,这些对象协作并产生返回主程序的结果,然后创建另外两个或三个以完成工作的下一个阶段,依此类推.

我觉得这种代码很容易理解和调试,以及使依赖注入变得容易.但它似乎违反了Tell Do Not Ask原则,并使主程序太胖了.我喜欢主要是如此小而且非常明显以至于不需要单元测试的想法.并告诉不要问我告诉我,如果一切都以A开头并以A结尾,那么这是A的责任.假设A是被计费的客户,并且客户拥有开始计费过程所需的数据以及发票需要在最后发送到的电子邮件地址.然后似乎A应该自己完成工作(main可以调用Customer.billYourself()),而不是通过给main发送一堆发票和一个电子邮件地址来将reponsibility交给main.

那么,我应该避免依赖链,使DI更容易,或者因为Tell Do not Ask而拥抱它们吗？

解决方法

类具有许多依赖项.这只是生活中的一个事实.但这就是那些阶级依赖于彼此的方式,使整个事情变得好或坏.

您应该阅读有关Stable Dependencies Principle的信息.如果遵循此规则,依赖项的数量应该不是问题：

THE DEPENDENCIES BETWEEN PACKAGES IN A DESIGN SHOULD BE IN THE
DIRECTION OF THE STABILITY OF THE PACKAGES. A PACKAGE SHOULD ONLY DEPEND UPON PACKAGES THAT ARE MORE STABLE THAN IT IS.

存在良好的依赖关系,并且存在错误的依赖关系：

Thus,we can say that a “Good Dependency” is a dependency upon
something with low volatility. The less volatile the target of the
dependency,the more “Good” the dependency is. By the same token a
“Bad Dependency” is a dependency upon something that is volatile. The
more volatile the target of the dependency is,the more “Bad” the
dependency is.

构建您的应用程序以具有良好的依赖性.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!