方法重载一直是一个充满喜忧参半的话题。 我们已经在博客上介绍了它，并介绍了几次警告：

• 您会后悔对Lambdas应用重载！
• 保持干燥：方法重载
• 为什么每个人都讨厌操作员超载
• API设计师，请小心

重载有用的主要原因有两个：

1. 允许使用默认参数
2. 允许分离的参数类型替代

Bot原因仅仅是出于为API使用者提供便利的目的。 在JDK中很容易找到很好的例子：

默认参数

public class Integer {public static int parseInt(String s) {return parseInt(s,10);}public static int parseInt(String s, int radix) {}
}

在上面的示例中，第一个parseInt()方法只是使用最常用的基数调用第二个方法的一种简便方法。

析取参数类型替代

有时，使用不同类型的参数可以实现相似的行为，这意味着相似的事物，但在Java的类型系统中不兼容。 例如，当构造一个String ：

public class String {public static String valueOf(char c) {char data[] = {c};return new String(data, true);}public static String valueOf(boolean b) {return b ? "true" : "false";}// and many more...
}

如您所见，根据参数类型优化了相同方法的行为。 由于两个valueOf()方法的语义相同，因此在读写源代码时这不会影响该方法的“感觉”。

此技术的另一个用例是常用时，相似但不兼容的类型需要在彼此之间方便地转换。 作为API设计人员，您不想让这样繁琐的转换使您的API消费者感到无聊。 相反，您提供：

public class IOUtils {public static void copy(InputStream input, OutputStream output);public static void copy(InputStream input, Writer output);public static void copy(InputStream input, Writer output, String encoding);public static void copy(InputStream input, Writer output, Charset encoding);
}

这是一个很好的示例，它同时显示了默认参数（可选编码）以及参数类型替代项（ OutputStream与Writer或String与Charset编码表示形式）。

边注

我怀疑联合类型和默认参数船很早以前就已经为Java航行了-尽管联合类型可能被实现为语法糖，但是默认参数将是引入JVM的野兽，因为它将取决于JVM对Java的缺少支持。命名参数。

正如Ceylon语言所显示的那样，这两个功能覆盖了所有方法重载用例的99％，这就是为什么Ceylon可以在不重载的情况下完全完成-在JVM之上！

超载是危险且不必要的

上面的示例表明，重载实质上只是帮助人们与API交互的一种手段。 对于运行时，没有重载之类的东西。 调用仅以字节码“静态”链接到不同的，唯一的方法签名（给出或采用更新的操作码，例如invokedynamic）。 但是要点是，对于上述计算机，如果上述方法全部都称为copy() ，或者被明确地调用了m1() ， m2() ， m3()和m4() ，则对计算机没有区别。

另一方面，重载在Java源代码中是真实的，并且编译器必须做大量工作才能找到最具体的方法，否则将应用JLS的复杂重载解析算法。 每个新的Java语言版本都会使情况变得更糟。 例如，在Java 8中，方法引用将给API使用者带来更多痛苦，并且需要API设计人员的额外照顾。 考虑一下Josh Bloch的以下示例：

//发现bug静态void pfc（List <Integer> x）{x.stream（）。map（Integer :: toString）.forEach（s-> System.out.println（s.charAt（0）））; }

— Joshua Bloch（@joshbloch） 2015年7月20日

您可以将上面的代码复制粘贴到Eclipse中，以验证编译错误（请注意，最新的编译器可能会报告类型推断副作用，而不是实际错误）。 Eclipse为以下简化报告了编译错误：

static void pfc(List<Integer> x) {Stream<?> s = x.stream().map(Integer::toString);
}

…是

Ambiguous method reference: both toString() and 
toString(int) from the type Integer are eligible

糟糕！

上面的表达是模棱两可的。 它可以表示以下两个表达式之一：

// Instance method:
x.stream().map(i -> i.toString());// Static method:
x.stream().map(i -> Integer.toString(i));

可以看出，使用lambda表达式而不是方法引用可以立即解决歧义。 解决此歧义（朝向实例方法）的另一种方法是改用toString()的超类型声明，该声明不再模糊不清：

// Instance method:
x.stream().map(Object::toString);

结论

API设计者的结论非常清楚：

自Java 8以来，方法重载已成为API设计人员更加危险的工具。

尽管上述内容并非真正“严峻”，但当API使用者的编译器拒绝看似正确的代码时，他们将花费大量时间来克服这种认知上的摩擦。 从该示例中获取的一个大人造假菜是：

切勿混合使用类似的实例和静态方法重载

实际上，这会放大您的静态方法重载何时重载java.lang.Object的名称， 正如我们在先前的博客文章中所解释的那样 。

遵循以上规则很简单。 因为只有两个有效的重载原因（默认参数和不兼容的参数替代），所以没有必要为同一类中的方法提供静态重载。 一个更好的设计（如JDK所公开）是具有“伴侣类”的，类似于Scala的伴侣对象。 例如：

// Instance logic
public interface Collection<E> {}
public class Object {}// Utilities
public class Collections {}
public final class Objects {}

通过更改方法的名称空间，可以在某种程度上很好地规避重载，并且不会出现以前的问题。

TL; DR：避免超载，除非增加的便利性真正增加了价值！

翻译自: https://www.javacodegeeks.com/2015/08/java-8s-method-references-put-further-restrictions-on-overloading.html