将null传递给可接受的方法

Question

Null对我来说是一种奇怪的数据类型，似乎它曾经是错误的使用，也许它的空指针错误我经常作为一个初学者，现在让我将任何null的实例与某种邪恶联系起来！

无论如何我的问题是

在某些情况下可以使用null作为参数吗？例如，一个方法可能需要a和b来完成一项任务，但在某些情况下它可能只需要一个。在那些奇怪的实例中为b解析为null，并检查是否（b == null）然后我们知道它叫什么？

还是我在这里的标志？

我必须承认，让我想知道这是否可以接受的是，所讨论的方法可以重叠，但是整个方法可能会有5或6行的差异。这让我担心代码重复。

Answer 1

将null传递给方法绝对没问题。但是，如果您有可能不需要传递变量的csae，请考虑overloading。

您可能传递null的原因是因为您可能有一个方法具有相当多的参数，并且您不想实现所有可能的重载。

我个人不使用可选参数 - 由于方法作为合同存在问题，因此对此主题进行了很多讨论超出了这个问题的范围。

---

更新

正确的方法不是重复代码，而是让重载相互调用：

public void Foo(A a)
{
    Foo(a, null);
}
public void Foo(A a, B b)
{
        // .......
}

这将告诉客户这段代码：

• 您只能使用A调用方法
• 您可以使用A和B调用方法

如果我只有第二种方法，客户端不知道是否可以通过null 。

Answer 2

我认为这是不确定。传递null并不是一个好习惯，在我看来，只要值为null，它就应该是一个例外。您可能无法始终控制数据的传递方式，在这种情况下，您应该检查是否存在以防万一。但是，如果您可以选择自己控制参数，则应该重载方法，而不是传入null。

考虑以下情况：

public string DoSomething(string a, string b)
{
   // Returns something after a and b is processed.
}

在这个例子中，我们指出a和b是字符串。它们是char []类型的对象，但是您想要定义一个字符串。 在这个方法中传入null根本就没有意义，因为我们期待字符串。 null不是什么 - 它不是一个空字符串 - 它只是无效。

我之所以说我不认为最好将null发送到方法中是因为null从未使用过任何用途。它只是一个空白，作为一个未能实现的东西的占位符。因此，调用上面的方法如下：

DoSomething（“无论如何”，null）毫无意义。

我们可以争辩说我们可以这样做：

/// <summary>
/// Does something with string a or b
/// </summary>
/// <param name="a">The first string. If it's null, nothing is done with it</param>
/// <param name="b">The second string. If it's null, nothing is done with it</param>
/// <returns></returns>
public string DoSomething(string a, string b)
{
    // Returns something after a and b is processed.
}

但这也使代码的可读性降低。为什么不进行重载DoSomething（字符串a）？或者可能完全重构该方法，因为它可以对a和null执行某些操作并仍然返回有效值。 null不是有效值，因此包含null作为参数的操作的结果不应返回有效值。

就像在数学中使用无穷大一样。如果你用它加/减，乘或除以某些东西，你总会得到无穷大。

声明

这些是我自己的观点，绝不是“正确”的编程方式。但由于这个问题没有正确的答案，我将练习言论自由的权利：）

Answer 3

如果您不使用某些参数，可以在C＃4.0中使用Overloading或Optional Parameters

Answer 4

您是说“将null作为参数传递给方法是否可以？”

如果是的话 - 是的 - 这是完全可以接受的。

但是，在.Net 4.0世界中，您可能需要考虑使用可选参数，这样您甚至不需要传入null，您可以省略它。

在.Net 4.0之前的世界中，如果将此null传递给方法是一种常见方案，则可能需要创建一个根本不接受参数的重载。

Answer 5

这是完全可以接受的。如果您使用的是C＃4.0，还可以创建参数optional，以便调用者不需要指定默认值。