我正在查看 Orchard CMS 项目的源代码，我注意到他们的一些构造函数从未验证所需的参数不为空。起初，我认为这很奇怪。我问自己，“考虑到你说这个依赖是必需的，你不想检查你是否真的有一个吗？” 意识到该项目使用 Castle Windsor 作为 IoC 容器，我后来想，“好吧，当容器试图找到具有需求的对象的依赖项时，它会抛出异常。” 所以我的问题是，当我知道 IoC 容器会为我检查时，我还应该检查吗？
或者双重检查是好的，因为从某种意义上说，我坚持反向封装原则：“我不知道我是如何获得这种依赖关系的，但我真的需要一个！”
我被引导遵循检查每个可见参数是否为 NULL 的做法，无论它是如何被设计为实例化的。总有可能有人会选择一个不同的 IoC 容器来执行更宽松的类型委托策略，或者一些初级开发人员找到您的代码并希望它能够按照他们想要的方式工作。
不管怎样，安全总比后悔好。在这种情况下，最好花几秒钟的时间来保护代码，然后花几个小时当有人决定将其用作意外时。
我不会检查。我认为这会不必要地使您的构造函数混乱。
如果您的 DI 容器没有所需的依赖项，那么您的手动或自动测试应该很快就会发现这一点。
通过将某些东西作为构造函数的参数，您是在说它是必需的。
另外，如果你以某种方式得到一个空参数，你会怎么做？
构造函数是否尝试构造一个新的 null 类型？可能不是因为这个构造函数不知道传入的类型需要实例化自己。
此时，您应该只捕获异常并优雅地退出或继续；但无论如何你应该有这种情况的代码。
是的。类设计必须不知道其依赖项是如何注入的，并且必须始终保护其不变量。
最新版本的 Ninject 和 Structure map 在你进入构造函数之前都会抛出一个绑定异常。因此，在构造函数中检查参数 null 异常无论如何都无济于事。
所以我投票赞成保持你的代码干净。
我并不是说防御性代码没有位置，但如果您使用现代 IoC，则构造函数检查不是一个。
尽管将来总有可能有人会选择不强制执行严格类型委托策略的不同 IoC 容器。我觉得这是一个“假设”的论点，改变 IoC 是一个相当大的架构决策，个人而言，自动生成空检查的成本可能不会太大。
对我来说，有人进来并需要阅读您的代码的可能性要高得多。更容易阅读的代码通常不太可能出现错误，并且维护起来也更快。