为什么要“避免方法重载”？

为什么Jorge Ortiz建议避免方法重载？

重载使将方法提升为功能更加困难：

object A {
   def foo(a: Int) = 0
   def foo(b: Boolean) = 0
   def foo(a: Int, b: Int) = 0

   val function = foo _ // fails, must use = foo(_, _) or (a: Int) => foo(a)
}

您不能有选择地导入一组重载方法中的一个。

尝试应用隐式视图以使参数适应参数类型时，出现歧义的可能性更大：

scala> implicit def S2B(s: String) = !s.isEmpty                             
S2B: (s: String)Boolean

scala> implicit def S2I(s: String) = s.length                               
S2I: (s: String)Int

scala> object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }
<console>:15: error: ambiguous reference to overloaded definition,
both method foo in object test of type (b: Boolean)Int
and  method foo in object test of type (a: Int)Int
match argument types (java.lang.String)
       object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }

它可以悄悄地使默认参数不可用：

object test { 
    def foo(a: Int) = 0; 
    def foo(a: Int, b: Int = 0) = 1 
}

单独地，这些原因并不强迫您完全避免超载。我觉得我缺少一些更大的问题。

更新

证据在堆积。

• 它使规格复杂
• 它可能导致隐式不适合在视图范围内使用。
• 它限制您仅在一种重载替代方案中引入参数的默认值。
• 由于将键入的参数没有预期的类型，因此您不能将像_.foo这样的匿名函数文字作为重载方法的参数传递。

更新2

• 您（当前）不能在包对象中使用重载方法。
• 对于API的调用者来说，适用性错误很难诊断。

更新3

• 静态重载解决方案可能会破坏所有类型的API：

scala> object O { def apply[T](ts: T*) = (); def apply(f: (String => Int)) = () }
defined object O

scala> O((i: String) => f(i)) // oops, I meant to call the second overload but someone changed the return type of `f` when I wasn't looking...

Gilad和Jason（重新命名）给出的原因都是避免过载的很好理由。吉拉德（Gilad）的原因集中于为什么重载通常是有问题的，而杰森（Jason）的原因集中于为什么在其他Scala功能的上下文中重载是有问题的。

在Jason的列表中，我要补充一点，重载与类型推断的交互作用很差。考虑：

val x = ...
foo(x)

推断类型的x更改可能会更改foo调用哪个方法。该值的x需求不会改变，只是推断类型的x，这可能发生的各种原因。

由于给出的所有原因（还有更多我敢忘的原因），我认为应尽量少使用方法重载。

我认为建议不是特别针对scala的，而是针对OO的（到目前为止，我知道scala应该是OO和功能之间的最佳选择）。

覆盖很好，它是多态性的核心，并且是OO设计的核心。

另一方面，过载更成问题。使用方法重载很难辨别哪个方法将被真正调用，并且确实经常引起混淆。也很少有理由说明为什么确实需要重载。大多数时候，问题可以用另一种方法解决，我同意超载是一种气味。

这里的一篇文章很好地解释了“超载是混乱的根源”的含义，我认为这是不鼓励这样做的主要原因。它适用于Java，但我认为它也适用于Scala。