为什么.NET中的'out'参数是个坏主意？

为什么.NET中的'out'参数是个坏主意？

我最近被问过这个问题,但我没有真正的答案,只是它不必要地使应用程序复杂化.还有其他什么原因？

1> Armin Ronach..：

---

嗯,我认为这不是一个坏主意. Dictionary有一个TryGetValue方法,这是一个非常好的例子,为什么输出参数有时是一件非常好的事情.

当然,你不应该过度使用这个功能,但根据定义,这不是一个坏主意.特别是在C#中你必须out在函数声明和调用中写下关键字,这使得它显而易见.

---

不你错了.对象的内容可能会改变,但是对象本身不能**交换**到另一个对象,除非你用`ref`或`out`传递它.这是那些修饰语中的真正意义!是的,我同意这会严重影响功能范式.但它有时还有其优点.

2> GvS..：

---

他们是个好主意.因为有时您只想从一个方法返回多个变量,并且您不希望为此创建"重"类结构.包装类结构可以隐藏信息流的方式.

我用它来:

在一次通话中返回密钥和IV数据

将人名拆分为不同的实体(名字,中间名,姓名)

拆分地址

---

"因为它会增加代码的复杂性".使用out参数而不是用户定义的类型会使代码编写起来不那么复杂.但它使代码阅读变得更加复杂.Out参数混淆了方法参数传递的正常语义.大多数人发现其参数是输入的函数,其返回值是输出更容易理解.如果你想完全使用参数,那么完全避免返回值会更直接,而是需要所有输出作为输出参数.然后,使用您的代码的人可以在一个地方找到输出.

---

因为它会增加代码的复杂性.您已经为额外类型添加了依赖项,而不是简单的调用.

---

错误。至少在2018年。返回一个元组。

3> Ben Hardy..：

---

如果你关心通过采用不变性和消除副作用来编写可靠的代码,那么输出参数是一个绝对可怕的想法.它会强制您创建可变变量来处理它们.(并不是C#支持只读方法级别的变量(至少在我使用的版本中,3.5)).

其次,它们通过强制开发人员设置和处理接收out值的变量来减少函数的组合性.这是令人讨厌的仪式.你不能只是轻松地使用它们来编写表达式.因此,调用这些函数的代码很快变成了一个很大的命令性混乱,提供了许多隐藏错误的地方.

---

这就是Option/Maybe monad的用途.

4> ChaosSpeeder..：

---

Out - 参数在我看来是个坏主意.它们增加了副作用的风险并且难以调试.唯一好的解决方案是函数结果,这就是问题:对于函数结果,您必须为每个复杂结果创建元组或新类型.现在在c#中应该相当容易,使用匿名类型和泛型.

顺便说一句:我也讨厌副作用.

5> Mark Cidade..：

---

问题的措辞是的"你打停止你的妻子？" 品种 -it假设out参数一定是个坏主意.在有些情况下的情况下进行参数可能会被滥用,但...

它们实际上非常适合C#语言.它们与ref参数类似,只是保证方法为其赋值并且调用者不需要初始化变量.

函数的正常返回值被压入堆栈,在那里调用和退出它们.当您提供out参数时,您将为该方法提供特定的内存地址以粘贴结果.这也允许多个返回值,但使用结构通常更有意义.

它们非常适合TryParse模式,并且还提供其他内容的元数据,例如SQL-CLR,其中out参数映射到存储过程签名的out参数.