可选参数在.NET中全面开花

.NET一直都支持可选参数，但是C#语言却并不支持，除了调用COM库以外，可选参数通常是被禁止使用的。现在，随着C# 4对可选参数的支持，我们可以看到可选参数被越来越多的使用，而不仅仅限于遗留代码中。这些应用包括与动态语言的互操作、只读数据类型，以及ASP.NET MVC中的许多地方。

显然，COM仍然是可选参数的主要用武之地。例如，当你使用Office库时，某个函数可能会有超过20个参数，手动指定每一个参数是非常不方便的。如果再没有辅助的标记，你就只能通过数参数的个数来确定哪个值对应的是哪个参数了，这非常容易出错。对于不熟悉COM的人，你可以想象一下从前主流语言不支持函数重载时的情景，那是一样的感觉。由于包含可选参数的函数和一般的函数没有区别，因此可以很好的解决这个问题。

除了COM之外，C#团队还利用C# 4作为晚绑定的途径来支持DLR。事实上，这才是可选参数真正的目的，其他都是附带的便利。由于动态语言没有显式的类型声明，无法基于参数类型进行函数重载，因此可选参数是非常必要的。

随着多核、多处理器计算机的增长，对于同步与并发的讨论也越来越多。只读数据类型以及如何定义它们成为了一个普遍的话题。如果类型中的每个字段都需要被设置，那么标准的构造函数就可以解决问题。但如果类型中的大部分字段都是可选的，就比较麻烦了。重载构造函数可以解决一部分问题，而对于使用Java或者旧版本C#的人来说，他们可能会更倾向于使用Builder模式。但如果有了可选参数，只需要一个构造函数就可以解决问题了。ASP.NET MVC 2中的Controller现在可以为query string参数设置默认值了。虽然你也可以使用attribute来设置，但可选参数是最简洁的办法。

微软为ASP.NET MVC推出的新视图引擎Razor，在helper方法中使用了可选参数。这让helper可以包含更多选项的同时，也支持自说明的编码风格。此外，Razor还会自动将表达式转换为委托，而不需要使用lambda或匿名委托的语法。

还有一些我们永远都不希望使用可选参数的地方。CLS定义了CLR的一个子集，所有.NET语言都要支持这个子集。CLS就明确定义，不可以依赖可选参数。这意味着可选参数将不会出现在BCL中，而且可能也不会出现在今后所有.NET Framework包含的类库中。但对于CodePlex上的非官方类库来说，这条规则不需要严格遵守。