是否应该在C＃4.0中使用重载或可选参数声明方法？

我正在看Anders谈论C＃4.0和C＃5.0的预览，这让我开始思考，何时可选参数在C＃中可用，这是声明不需要指定所有参数的方法的推荐方式？

例如，类似FileStream该类的东西有大约十五个不同的构造函数，这些构造函数可以划分为逻辑“族”，例如，字符串中的下面的那些，an中的一个IntPtr和a中的一个SafeFileHandle。

FileStream(string,FileMode);
FileStream(string,FileMode,FileAccess);
FileStream(string,FileMode,FileAccess,FileShare);
FileStream(string,FileMode,FileAccess,FileShare,int);
FileStream(string,FileMode,FileAccess,FileShare,int,bool);

在我看来，可以通过以下方法简化这种类型的模式：改为使用三个构造函数，并对可以默认使用的参数使用可选参数，这将使不同的构造函数系列更加不同[注：我知道此更改不会在BCL中完成，我假设是针对这种情况]。

你怎么看？从C＃4.0开始，将密切相关的构造函数和方法组作为具有可选参数的单个方法会更有意义，还是有充分的理由坚持传统的多次重载机制？

我会考虑以下几点：

• 您是否需要从不支持可选参数的语言中使用代码？如果是这样，请考虑包括重载。
• 您的团队中有没有成员强烈反对可选参数？（有时候，做出您不喜欢的决定要比对案件辩护容易。）
• 您是否确信在代码构建之间不会更改默认设置，或者如果可能，您的调用方会同意吗？

我没有检查默认值的工作方式，但我假设默认值将被烘焙到调用代码中，与对const字段的引用几乎相同。通常没关系-更改默认值非常重要-但这是要考虑的事情。

当方法重载通常使用不同数量的参数执行相同的操作时，将使用默认值。

当方法重载根据其参数以不同的方式执行功能时，将继续使用重载。

在VB6的日子里，我使用了可选的方法，但是由于错过了它，它将减少C＃中许多XML注释的重复。

我一直在使用带有可选参数的Delphi。我改用了过载。

因为当您创建更多重载时，您总是会与可选参数形式发生冲突，然后无论如何都必须将它们转换为非可选参数。

我喜欢这样一种观念，即通常存在一种超级方法，而其余的则是围绕该方法的更简单的包装。

我一定会使用4.0的可选参数功能。它摆脱了荒谬的...

public void M1( string foo, string bar )
{
   // do that thang
}

public void M1( string foo )
{
  M1( foo, "bar default" ); // I have always hated this line of code specifically
}

...并将值放在调用者可以看到的位置...

public void M1( string foo, string bar = "bar default" )
{
   // do that thang
}

更简单，更少出错。我实际上已经将其视为过载情况下的错误...

public void M1( string foo )
{
   M2( foo, "bar default" );  // oops!  I meant M1!
}

我还没有玩过4.0编译器，但是得知编译器只是为您发出了重载，我不会感到震惊。

可选参数本质上是一段元数据，它指示正在处理方法调用的编译器在调用位置插入适当的默认值。相比之下，重载提供了一种方法，编译器可以通过该方法选择许多方法之一，其中一些方法本身可能会提供默认值。请注意，如果尝试从不支持该语言的语言编写的代码中调用指定可选参数的方法，则编译器将要求指定“可选”参数，但是由于调用未指定可选参数的方法是等效于使用等于默认值的参数调用它，此类语言调用此类方法没有障碍。

在调用站点绑定可选参数的一个重要结果是，将根据编译器可用的目标代码的版本为它们分配值。如果程序集Foo具有Boo(int)默认值为5的方法，而程序集Bar包含对的调用Foo.Boo()，则编译器会将其作为进行处理Foo.Boo(5)。如果默认值更改为6并Foo重新编译了程序集，Bar则将继续调用，Foo.Boo(5)除非或直到使用新版本的进行重新编译为止Foo。因此，应该避免对可能发生变化的事物使用可选参数。

可以争论是否应该使用可选参数或重载，但是最重要的是，每个参数都有其自己的区域，这些区域是不可替代的。

当与命名参数结合使用时，可选参数与COM调用的一些带有所有可选参数的长参数列表结合使用时非常有用。

当方法能够对许多不同的参数类型进行操作（仅是示例之一）并且在内部进行强制转换时，重载非常有用。您只需提供有意义的任何数据类型（某些现有的重载即可接受）。不能用可选参数击败它。

我期待可选参数，因为它使默认值更接近该方法。因此，您只需定义一次方法即可，而不必为调用“ expanded”方法的重载使用数十行代码，而只需在方法签名中看到可选参数的默认值即可。我宁愿看：

public Rectangle (Point start = Point.Zero, int width, int height)
{
    Start = start;
    Width = width;
    Height = height;
}

代替这个：

public Rectangle (Point start, int width, int height)
{
    Start = start;
    Width = width;
    Height = height;
}

public Rectangle (int width, int height) :
    this (Point.Zero, width, height)
{
}

显然，该示例非常简单，但是在OP中有5个重载的情况下，事情很快就会变得拥挤。

我最喜欢的可选参数方面之一是，即使不进行方法定义，也可以查看如果不提供参数会发生什么情况。当您键入方法名称时，Visual Studio只会向您显示该参数的默认值。对于重载方法，您将不得不阅读文档（如果有的话）或直接导航到方法的定义（如果有的话）以及重载包装的方法。

特别是：随着超载量的增加，文档工作量可能会迅速增加，您可能最终会从现有的超载中复制已经存在的注释。这很烦人，因为它不产生任何值并且破坏了DRY原理。另一方面，使用可选参数，恰好在一个地方记录了所有参数，并且在键入时会看到它们的含义以及默认值。

最后但并非最不重要的一点是，如果您是API的使用者，您甚至可能没有选择检查实现细节（如果您没有源代码），因此没有机会查看重载的方法是哪种超级方法。包装。因此，您不得不阅读文档并希望在那里列出所有默认值，但情况并非总是如此。

当然，这不是一个涵盖所有方面的答案，但我认为它增加了一个到目前为止尚未涉及的答案。

尽管它们（据说？）有两种在概念上等效的方法可供您从头开始建模API，但不幸的是，当您需要考虑旧客户端的运行时向后兼容性时，它们有一些细微的差别。我的同事（感谢Brent！）向我指出了这一精彩的文章：带有可选参数的版本控制问题。引述一下：

首先将可选参数引入C＃4的原因是为了支持COM互操作。而已。现在，我们正在了解这一事实的全部含义。如果您的方法带有可选参数，则由于担心会导致编译时中断更改，因此永远无法添加带有其他可选参数的重载。而且，您永远无法消除现有的重载，因为这一直是运行时的重大更改。您几乎需要将其视为接口。在这种情况下，您唯一的办法是使用新名称编写新方法。因此，如果您打算在API中使用可选参数，请注意这一点。

可选参数的一个警告是版本控制，其中重构会产生意想不到的后果。一个例子：

初始码

public string HandleError(string message, bool silent=true, bool isCritical=true)
{
  ...
}

假设这是上述方法的许多调用者之一：

HandleError("Disk is full", false);

在这里，事件不是静默的，而是被视为紧急事件。

现在让我们说重构之后，我们发现所有错误都会提示用户，因此我们不再需要静默标志。因此，我们将其删除。

重构后

前一个调用仍然可以编译，并且可以说它在重构过程中保持不变：

public string HandleError(string message, /*bool silent=true,*/ bool isCritical=true)
{
  ...
}

...

// Some other distant code file:
HandleError("Disk is full", false);

现在false将产生意想不到的效果，该事件将不再被视为紧急事件。

这可能会导致细微的缺陷，因为将不会出现编译或运行时错误（与其他可选警告（例如this或this）不同））不同）。

请注意，同一问题有多种形式。这里概述了另一种形式。

另请注意，在调用方法时严格使用命名参数可以避免此问题，例如：HandleError("Disk is full", silent:false)。但是，假设所有其他开发人员（或公共API的用户）都将这样做是不切实际的。

由于这些原因，除非有其他令人信服的考虑因素，否则我将避免在公共API中使用可选参数（如果可能被广泛使用，甚至不要使用公共方法）。

这两个Optional参数，Method重载都有其优点或缺点。这取决于您的选择偏好。

可选参数：仅在.Net 4.0中可用。可选参数可减少代码大小。您无法定义out和ref参数

重载的方法：您可以定义Out和ref参数。代码大小会增加，但是重载的方法很容易理解。

在许多情况下，使用可选参数来切换执行。例如：

decimal GetPrice(string productName, decimal discountPercentage = 0)
{

    decimal basePrice = CalculateBasePrice(productName);

    if (discountPercentage > 0)
        return basePrice * (1 - discountPercentage / 100);
    else
        return basePrice;
}

这里的Discount参数用于提供if-then-else语句。存在未被识别的多态性，然后将其实现为if-then-else语句。在这种情况下，最好将两个控制流分成两个独立的方法：

decimal GetPrice(string productName)
{
    decimal basePrice = CalculateBasePrice(productName);
    return basePrice;
}

decimal GetPrice(string productName, decimal discountPercentage)
{

    if (discountPercentage <= 0)
        throw new ArgumentException();

    decimal basePrice = GetPrice(productName);

    decimal discountedPrice = basePrice * (1 - discountPercentage / 100);

    return discountedPrice;

}

这样，我们甚至保护了该类，使其免于接听零折扣的电话。该呼叫意味着呼叫者认为有折扣，但实际上根本没有折扣。这种误解很容易导致错误。

在这种情况下，我不希望没有可选参数，而是要强制调用者显式选择适合其当前情况的执行方案。

这种情况与具有可以为null的参数非常相似。当实现变成类似的语句时，这同样是一个坏主意if (x == null)。

您可以在以下链接上找到详细的分析：避免使用可选参数和避免使用空参数

要在使用重载而不是可选内容时添加一个简单的方法：

只要您有多个只能一起使用的参数，就不要在其上引入可选参数。

或更笼统地说，只要方法签名启用了没有意义的用法模式，就限制可能的调用的排列数量。例如，通过使用重载代替可选的重载（顺便说一句，当您具有相同数据类型的多个参数时，此规则也适用；这里，工厂方法或自定义数据类型之类的设备可以提供帮助）。

例：

enum Match {
    Regex,
    Wildcard,
    ContainsString,
}

// Don't: This way, Enumerate() can be called in a way
//         which does not make sense:
IEnumerable<string> Enumerate(string searchPattern = null,
                              Match match = Match.Regex,
                              SearchOption searchOption = SearchOption.TopDirectoryOnly);

// Better: Provide only overloads which cannot be mis-used:
IEnumerable<string> Enumerate(SearchOption searchOption = SearchOption.TopDirectoryOnly);
IEnumerable<string> Enumerate(string searchPattern, Match match,
                              SearchOption searchOption = SearchOption.TopDirectoryOnly);