重构保护条款
人们采用什么方法（如果有的话）管理class级中的保护条款爆炸？ 例如：
public void SomeMethod(string var1, IEnumerable items, int count) { if (string.IsNullOrEmpty(var1)) { throw new ArgumentNullException("var1"); } if (items == null) { throw new ArgumentNullException("items"); } if (count < 1) { throw new ArgumentOutOfRangeException("count"); } ... etc .... } 在我目前正在进行的项目中，有许多类在公共方法上具有类似的一组保护条款。
我知道.NET 4.0代码合同，但目前这不是我们团队的选择。
我见过很多项目都使用静态Guard类。
public static class Guard { public static void ArgumentIsNotNull(object value, string argument) { if (value == null) throw new ArgumentNullException(argument); } }
在我看来，它使代码更清晰。
Guard.ArgumentIsNotNull(arg1, "arg1");
如果您不想沿着Code Contracts路线前进，简化它的一种方法是删除大括号：
public void SomeMethod(string var1, IEnumerable items, int count) { if (string.IsNullOrEmpty(var1)) throw new ArgumentNullException("var1"); if (items == null) throw new ArgumentNullException("items"); if (count < 1) throw new ArgumentOutOfRangeException("count"); ... etc .... }
除此之外，如果您的异议是.Net 4.0还不是黄金时间，那么有一些方法可以模拟代码合约：
http://geekswithblogs.net/Podwysocki/archive/2008/01/22/118770.aspx
您可以考虑重构以引入Null对象 。
与此同时，这里有一篇很好的文章： http ： //haacked.com/archive/2013/01/05/mitigate-the-billion-dollar-mistake-with-aspects.aspx/
我会考虑使用NullGuard.Fody，因为我对Fodys减少样板代码的能力感到兴奋
减少（不完全删除）保护条款数量的一种方法是了解其存在的原因。 通常情况下，我们会防止对参数类型有效的值，但对接受它们的方法无效。 换句话说，方法是在由参数类型定义的域的子集上定义的。
此类案例的解决方案是尝试定义子类型（例如，更具限制性的接口）并接受该类型作为参数。 您可以在本文中找到一个说明性示例： 为什么我们需要保护条款？
当然，这种技术并不适用于所有情况。 所有引用类型至少允许空引用。 因此，我们的大多数方法都将在域的一部分上定义，而这又需要一个针对null的保护子句。
但从积极的方面来说，这种技术有助于提高对接收比期望更普遍的参数的方法的认识。 管道那个孔有助于改善设计。