重构保护子句

Question

人们采取什么方法（如果有的话）来管理类中的保护条款爆炸？例如：

public void SomeMethod<T>(string var1, IEnumerable<T> 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 代码合同，但是目前我们团队还没有选择。

Answer 1

我见过的很多项目都使用静态 Guard 类。

public static class Guard {
    public static void ArgumentIsNotNull(object value, string argument) {
        if (value == null)
            throw new ArgumentNullException(argument);
    }
}

在我看来，它使代码更加简洁。

Guard.ArgumentIsNotNull(arg1, "arg1");

Answer 2

您可以考虑重构为引入空对象。

Answer 3

同时，这里有一篇关于此的优秀文章： http://haacked.com/archive/2013/01/05/mitigate-the-billion-dollar-mistake-with-aspects.aspx/

我会考虑使用 NullGuard.Fody 因为我对 Fody 减少样板代码的能力感到兴奋

Answer 4

减少（而不是完全消除）保护子句数量的一种方法是了解它们存在的原因。很多时候，我们会防范对参数类型有效但对接受它们的方法无效的值。换句话说，方法是在参数类型定义的域的子集上定义的。

此类情况的解决方案是尝试定义一个子类型（例如，更具限制性的接口）并接受该类型作为参数。您可以在本文中找到一个说明性示例：为什么这样做我们需要保护子句吗？

当然，这种技术并不适用于所有情况。所有引用类型至少允许空引用。因此，我们的大多数方法将在域的一部分上定义，这反过来又需要一个针对 null 的保护子句。

但从积极的一面来看，这种技术有助于提高人们对接收比预期更笼统的参数的方法的认识。对该孔进行管道连接有助于改善总体设计。

Answer 5

如果您不想走代码契约路线，简化它的一种方法是删除大括号：

public void SomeMethod<T>(string var1, IEnumerable<T> 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