对于IoC容器，构造函数是否仍然检查参数是否为空？

我正在浏览Orchard CMS项目的源代码，我注意到他们的一些构造函数从未验证所需的参数是否为空。起初，我认为这很奇怪。我问我的自我，“考虑到你说这个依赖是必需的，难道你不想检查你确实有吗？”由于意识到该项目使用Castle Windsor作为IoC容器，我后来认为，“当它试图找到具有该要求的对象的依赖关系时，容器将抛出异常。”所以我的问题是，我是否应该知道IoC容器会检查我吗？对于IoC容器，构造函数是否仍然检查参数是否为空？

或者是双重检查，因为在某种意义上，我坚持反向封装原则，声明：“我不知道我是如何获得这种依赖关系，但我真的需要一个！

来源

2013-08-18 Chris

这是一篇有趣的文章由马克塞曼关于这个问题：http://blog.ploeh.dk/2013/07/08/defensive-coding/ – Steven

谢谢你....我一直在变得安静的风扇马克。我一直说你应该在处理之前检查方法的要求，因为当你遇到问题时它会使故障排除更容易。 – Chris

说实话，现在我不再检查构造函数的参数了，因为容器连接的类。我知道我的容器（和大多数容器）决不允许在构造函数中注入null。因此，在这种情况下忽略检查是安全的，并使代码更具可读性，更易于维护。 – Steven

我已经被引导遵循检查NULL的每个可见参数的做法，无论它是如何被设计为实例化的。总有一个机会，有人会选择一个不同的IoC容器来执行更宽松的类型委托策略，或者一些初级开发人员发现你的代码，并希望它能按照他们想要的方式工作。

无论哪种方式，比对不起更安全。在这种情况下，最好花几秒钟的时间来守护代码，然后在有人决定将其作为意外时使用。

来源

2013-08-18 04:25:22

这就是我一直认为的方式。但是这种情况让我意识到，在我所有的生产代码中，我从来没有因为IoC容器而抛出构造函数中的ArgumentNullException。只是在我的代码中看起来像额外的噪音。 – Chris

我不会检查。我认为这会不必要地混淆你的构造函数。

如果您的DI容器没有所需的依赖关系，那么您的测试，手动或自动应该很快就会捕捉到这一点。

通过有东西作为构造函数的参数，你说它是要求。

另外，如果你以某种方式得到一个空参数，你会怎么做？

构造函数是否试图构造一个新的空类型？可能不是因为这个构造函数不应该知道传入的类型需要实例化自己。

在这一点上，你应该赶上例外，优雅地退出或继续前进;但无论如何你都应该有这种情况的代码。

来源

2013-08-18 04:46:57 tom

只是扮演魔鬼的拥护者...在解决问题时，ArgumentNullException会不会更像是一个NullReferenceException？ – Chris

在编程方面，我认为我们处于偏好领域。 – tom

越小的方法得到的'NullReferenceException'就越少，因为更容易发现哪个引用是空的:-) – Steven

是的。类的设计必须不依赖于它的依赖注入，并且必须始终保护它的不变量。

来源

2013-08-18 13:25:02

Ninject和Structure map的最新版本将在输入构造函数之前抛出一个绑定异常。因此，在构造函数中检查参数null异常无论如何都无济于事。

所以我投票保持你的代码清洁。

我不是说防御性代码没有地方，但如果您使用现代IoC，构造函数检查不是一个地方。

尽管将来有人会有机会选择不强制执行严格类型委托策略的不同IoC容器。我觉得是一个“假设”的说法，改变IoC是一个非常大的架构决策，而且个人来说，自动生成空值检查的代价可能不会影响它。

对我来说，有人进来并需要阅读代码的可能性更高。更容易阅读代码通常不太可能是越野车，并且也更快维护。

来源

2013-12-10 09:45:51

对于IoC容器，构造函数是否仍然检查参数是否为空？

回答

相关问题