java方法重載和重載方法

方法重載一直是一個充滿喜憂參半的話題。 我們已經(jīng)在博客上介紹了它，并介紹了幾次警告：

• 您會后悔對Lambdas應用重載！
• 保持干燥：方法重載
• 為什么每個人都討厭操作員超載
• API設計師，請小心

重載有用的主要原因有兩個：

允許使用默認參數(shù)

允許分離的參數(shù)類型替代

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

默認參數(shù)

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

在上面的示例中，第一個parseInt()方法只是使用最常用的基數(shù)調(diào)用第二個方法的一種簡便方法。

析取參數(shù)類型替代

有時，使用不同類型的參數(shù)可以實現(xiàn)相似的行為，這意味著相似的事物，但在Java的類型系統(tǒng)中不兼容。 例如，當構(gòu)造一個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... }

如您所見，根據(jù)參數(shù)類型優(yōu)化了相同方法的行為。 由于兩個valueOf()方法的語義相同，因此在讀取或編寫源代碼時，這不會影響該方法的“感覺”。

此技術的另一個用例是常用時，相似但不兼容的類型需要在彼此之間方便地轉(zhuǎn)換。 作為一個API設計人員，您不想讓這樣繁瑣的轉(zhuǎn)換使您的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); }

這是一個很好的示例，它同時顯示了默認參數(shù)（可選編碼）以及參數(shù)類型替代項（ OutputStream與Writer或String與Charset編碼表示形式）。

邊注

我懷疑聯(lián)合類型和默認參數(shù)船很久以前就已經(jīng)為Java航行了-盡管聯(lián)合類型可能被實現(xiàn)為語法糖，但是默認參數(shù)將是引入JVM的野獸，因為它將取決于JVM對Java的缺少支持。命名參數(shù)。

正如Ceylon語言所顯示的那樣，這兩個功能覆蓋了所有方法重載用例的99％，這就是為什么Ceylon可以在不重載的情況下完全完成-在JVM之上！

超載是危險且不必要的

上面的示例表明，重載實質(zhì)上只是幫助人們與API交互的一種手段。 對于運行時，沒有重載之類的東西。 調(diào)用僅以字節(jié)碼“靜態(tài)”鏈接到不同的唯一方法簽名（給出或采用更新的操作碼，例如invokedynamic）。 但是關鍵是，如果上述方法都被稱為copy() ，或者被明確地調(diào)用了m1() ， m2() ， m3()和m4() ，則對于計算機而言沒有區(qū)別。

另一方面，重載在Java源代碼中是真實的，并且編譯器必須做大量工作才能找到最特定的方法，否則將應用JLS的復雜重載解析算法。 每個新的Java語言版本都會使情況變得更糟。 例如，在Java 8中，方法引用將給API使用者帶來更多痛苦，并需要API設計人員的額外注意。 考慮一下Josh Bloch的以下示例：

//發(fā)現(xiàn)bug靜態(tài)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表達式而不是方法引用可以立即解決歧義。 解決此歧義（朝向?qū)嵗椒?#xff09;的另一種方法是改用toString()的超類型聲明，該聲明不再模糊不清：

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

結(jié)論

API設計人員的結(jié)論很明確：

自Java 8以來，方法重載已成為API設計人員更加危險的工具。

盡管上述內(nèi)容并不是很“嚴重”，但當API使用者的編譯器拒絕看似正確的代碼時，它們將花費大量時間來克服這種認知上的摩擦。 從該示例中獲取的一個大人造舞弊是：

切勿混合使用類似的實例和靜態(tài)方法重載

實際上，這會放大您的靜態(tài)方法重載何時重載java.lang.Object的名稱， 正如我們在先前的博客文章中所解釋的那樣 。

遵循以上規(guī)則很簡單。 因為只有兩個有效的重載原因（默認參數(shù)和不兼容的參數(shù)替代），所以沒有必要為同一類中的方法提供靜態(tài)重載。 一個更好的設計（如JDK所公開）是具有“伴侶類”的，類似于Scala的伴侶對象。 例如：

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

通過更改方法的名稱空間，可以在某種程度上巧妙地避免重載，并且不會出現(xiàn)以前的問題。

TL; DR：除非增加了便利性才能真正帶來價值，否則請避免過載。

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

java方法重載和重載方法

總結(jié)

以上是生活随笔為你收集整理的java方法重载和重载方法_Java 8的方法参考进一步限制了重载的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。