unit-testing - 可以为普遍使用的依赖项使用服务定位器吗?

标签 unit-testing testing dependency-injection service-locator

我们在我们的代码库中严格遵守控制反转,但这会产生 hell 般的构造函数(是的,我知道这意味着我们的类不够内聚,这是一项正在进行的工作)。
问题是,有时这些依赖项非常愚蠢,例如启用日期模拟的 DateTime 包装器、记录器或 TaskFactory 包装器,它们与类的业务没有直接关系,我认为它们不需要显式介绍。

我们能否通过为那些在整个系统中传递的项目使用服务定位器来减轻 ctors 的负担?会有什么缺点?

最佳答案

Could we ease the load on our ctors by using a service locator for those items which are passed all over the system?

不,依赖关系仍然存在,但它不是显式的,现在是隐式的。

只要你有too many constructors arguments, at least you know that you have a problem .如果你引入一个服务定位器,你仍然有你原来的问题,但现在你也有 violated encapsulation .你只是让潜在的问题更难被发现,而没有解决任何问题。

Service Locator is a bona fide anti-pattern ;它解决不了任何问题。

关于unit-testing - 可以为普遍使用的依赖项使用服务定位器吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33944520/

相关文章:

unit-testing - 在测试版/原型(prototype)制作期间进行单元测试是个坏主意吗?

c++ - 组件测试的测试框架

javafx - 传递参数JavaFX FXML

java - Dagger2 如何基于java类进行注入(inject)?

unit-testing - NUnit GUI 未找到 app.config 文件

java - 在应用上下文中的 prop 标签中声明一个 Date 对象

javascript - moduleDirectories 键无法导入我的测试实用程序

c++ - 如何为 C++ 类和结构自定义 STAsertEquals 输出?

java - 为什么即使不使用 volatile,在一个线程中修改共享变量也会影响另一个线程?

node.js - Promise 的 Mocha 单元测试抛出错误