为什么.NET框架指南建议您不要使用ref/out参数?

你看到有多少开发人员不真正理解Ref/Out吗?

我把它们用在真正需要的地方,但不是别的地方。它们通常只有在您想要有效地返回两个或更多值时才有用-在这种情况下,它至少值得 思考 关于是否有一种方法可以使方法只做一件事。有时使用ref/out 是 最合适的方法-各种胰蛋白酶方法等。

在我看来,它们被认为是一种代码味道,因为通常有一个更好的选择:返回一个对象。

如果您注意到,在.NET库中,它们只在某些特殊情况下使用,即 三分法 -类似于以下情况:

• 返回类意味着将值类型装箱
• 该方法的契约要求它快速,因此装箱/拆箱不是一个可行的选项。

Ref/Out自动意味着易变性,具有不可变值的函数式编程在当今非常流行。尝试在Linq查询中插入对Dictionary.TryGetValue的调用。该API要求声明变量并破坏API中的任何“流畅性”。

这并不是说这是“原因”,而是“原因”的一个例子。

(也见)

http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!181.entry

有关函数语言如何处理此类API的说明。)

困惑可能是最好的原因。混淆意味着可维护性降低,并且增加了引入细微缺陷的可能性。我在类似于“goto”控制流语句的视图中看到它们。虽然它本身并不是坏的,但几十年来它已经导致许多无法阅读/理解的程序。

远离任何可能使代码变得更混乱的东西。

尽管如此,这些关键字的存在可能是因为框架开发人员认为需要这样的东西。如果没有合适的解决方法,可以使用它们,但尽可能避免使用它们。

Ref/Out也不适用于“func”委托,因此这些样式的API与使用委托的其他一些API的组合/可重用性较差。

只是一个想法,我发现当争论 捕获执行状态 而不是捕获返回的数据。当您希望从返回customer对象的服务中获取错误消息时,请考虑一个场景。

Customer GetCustomerById(int id, out string errorMessage);

如果此方法失败,您可能会返回空客户对象或引发异常。但是,如果我想知道错误的原因(验证?数据库?)我会用掉争论。这里的ErrorMessage参数与数据无关,只是用来捕获方法执行的错误。

就个人而言,如果我有一个方法可以返回两个或更多的基本数据/值,我会重新考虑代码的设计。

我被告知的原因是1.0 GC在使用ref/out时出现问题。2.0中的GC(可能也不是1.1)没有这些问题,所以我通常认为它是一个现在没有用处的遗留问题。

@ TraumaPony 如果您给我们一个这个.NET框架guidline的源代码(url或其他东西),那就好了。

您应该返回对象可能是他们建议不使用ref或out的最可能原因。

“ref”实际上只需要在传递标量值时使用,但我看到人们经常将其用于通过引用传递的对象。

代码复杂性是否足够?比较:

int myValue;
ReadFromSomewhere(ref myValue);

到:

int myValue = ReadFromSomewhere();