注入很少使用的服务 - 构造函数 vs 方法

Question

这个问题是关于主要基于价值对象和服务的可测试软件设计。

下面是一个可以将数据保存到文件的简单服务的 API 示例。

saveToFile(data, fileName)
saveToUniqueFile(data, fileNameGenerator)

fileNameGenerator是一种生成随机文件名的服务。它用于查找唯一的文件名以保存数据。在这个例子中fileNameGenerator是作为方法参数注入的。

替代方法之一是构造函数注入，它可以简化 API：

saveToFile(data, fileName)
saveToUniqueFile(data)

保存到唯一文件肯定不会每次都使用，因此似乎不需要强制构造函数参数。另一方面，服务通常通过数据进行通信，这里我们有一个服务，它确实使 API 有点混乱。

将服务作为方法参数传递是否有任何潜在的问题/不便？在这种情况下，构造函数注入仍然是首选吗？

Answer 1

将服务作为参数传递是很成问题的，因为你永远不知道什么时候需要它们。方法及其参数构成了您的 API，而构造函数则没有。使用构造函数注入服务为您提供了更大的自由度，因为它允许您将依赖项与方法表示的 API 分离。

否则，您必须将方法参数传递给 API 中的所有方法，以防它们中的一两个可能需要它。

即使服务只是偶尔使用一次，通过构造函数注入它们也很少成为问题。