【发布时间】:2013-01-14 23:48:59
【问题描述】:
假设,例如,我们有一个方法,为了论证,我们将其称为 MethodOne;
public void MethodOne()
{
//do stuff.
}
现在假设我们要创建一个可选参数,并且我们可能决定创建另一个具有相同名称的方法,例如采用不同的重载;
public void MethodOne()
{
//do stuff.
}
public void MethodOne(bool checkVar)
{
if(checkVar)
{
//do stuff
}
else
{
//do other stuff
}
}
所以现在我们有了一个方法,它有两种不同的重载组合(?)。在实践中,这是否比使用一种方法更好,例如只检查可选重载是否为空或包含信息;
public void MethodOne(int? testVar)
{
if(testVar != null)
{
//do stuff
}
}
这对于只有一个重载似乎微不足道,但想象一下我有 5 个要传递的变量,我会创建 5 个方法,不同重载的同名方法,还是只有一个方法并检查传递的变量?
【问题讨论】:
-
实际上,如果您有五个参数,并且它们都是可选的,那么您最终可能会得到多达 2^5=32 个重载。
-
这不是重点:P 但是,是的,我明白了。
-
如果你有一个有五个参数的方法,并且其中任何一个或所有参数都可以为空,你就会遇到不同的问题:你的方法可能做得太多,应该分成更小的方法,每个方法都有一个责任。
-
@Shane.C 这正是重点。如果你需要使用 32 个构造函数重载,那你就做错了 :)
-
正如 Daniel 指出的那样,您可能需要检查方法的内聚性。你所描述的听起来像是沟通凝聚力:你放在一起的代码是为了对相同的数据进行操作而放在一起的。通常建议争取更高的内聚力,比如功能内聚力,在这种情况下,方法中的所有代码都参与到一个定义明确的任务中。通过努力实现功能内聚,您的耦合应该自然而然地下降(您的参数不会成为太大的问题)