java方法重载和重载方法
方法重载一直是一个充满喜忧参半的话题。 我们已经在博客上介绍了它，并介绍了几次警告：
- 您会后悔对Lambdas应用重载！
- 保持干燥：方法重载
- 为什么每个人都讨厌操作员超载
- API设计师，请小心
重载有用的主要原因有两个：
- 允许使用默认参数
- 允许分离的参数类型替代
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
java方法重载和重载方法
