非类的依赖注入

Question

我对依赖注入有些新意。我已经为一些类设置了它们，这些类将它们的依赖项作为参数传递给构造函数，但是我有一些构造函数可以使用String或boolean等基元。显然，如果我要为该类使用依赖注入，则需要从构造函数中删除它们。

对于这样的案例，什么是“最佳”做法？使构造函数只接受依赖项并为该类所需的所有基元提供setter方法？

Answer 1

  

显然，如果我要为该类使用依赖注入，这些需要从构造函数中删除

不，不是“显然”。您可以保留这些参数以及注入依赖项。

如果类需要这些参数进行正确初始化，则它们必须是构造函数的一部分。

Answer 2

我的观察是，在大多数情况下，具有同时接受依赖关系和基元的构造函数的类会破坏Single Responsibility Principle或至少导致设计不那么干净，这导致容器配置更多脆弱而难以理解。

在大多数（如果不是全部）情况下，这些原语是配置值，例如连接字符串，调试选项等。

有几种方法可以改变您的设计来解决这个问题：

1. 如果您正在破坏SRP，请将代码提取为自己的类型。以NotifyCustomerHandler为string notificationServiceUrl，其中string需要NotificationService，而NotifyCustomerHandler应该被封装到某种INotifyCustomerHandlerConfiguration。
2. 另一种选择是将类型的配置值提取为自己的类型。对于IMyApplicationConfiguration，它可能依赖于{{1}}。在过去，我曾经有一个{{1}}接口，应用程序需要的所有配置值，但我得出结论，这是一个坏主意。这打破了this example，您的单元测试将开始受到可读性和可维护性的影响。
3. 如果您没有破坏SRP并且注入配置对象是不切实际的（当您有一个原语或获得太多配置接口，或者您只是不喜欢该选项时），您可以更改这些构造函数公共财产的论据。这将允许您（使用大多数容器）注册一个委托，该委托将在创建后配置实例，编译器可以通过这种方式为您验证。

Answer 3

类应该采用它需要的任何依赖项，以便执行其功能。它委托一些任务的其他服务，以及原始依赖（通常是一些配置值）。

任何非平凡的容器都会满足这种情况，并允许您这样做。 Here's for example how Castle Windsor does it