api中重載函數(shù)的原理

重載方法是API設(shè)計(jì)中的一個(gè)重要概念，尤其是當(dāng)您的API是流利的API或DSL（ 特定于域的語言 ）時(shí)。

對(duì)于jOOQ就是這種情況，在這種情況下，您經(jīng)常想使用與完全相同的方法名稱來與庫進(jìn)行各種交互。

示例：jOOQ條件

package org.jooq;public interface Condition {// Various overloaded forms of the "AND" operation:Condition and(Condition other);Condition and(String sql);Condition and(String sql, Object... bindings);// [...]}

所有這些方法都使用“ AND”運(yùn)算符將兩個(gè)條件相互關(guān)聯(lián)。 理想情況下，實(shí)現(xiàn)相互依賴，從而造成單點(diǎn)故障。 這會(huì)使事情變干 ：

package org.jooq.impl;abstract class AbstractCondition implements Condition {// The single point of failure@Overridepublic final Condition and(Condition other) {return new CombinedCondition(Operator.AND, Arrays.asList(this, other));}// "Convenience methods" delegating to the other one@Overridepublic final Condition and(String sql) {return and(condition(sql));}@Overridepublic final Condition and(String sql, Object... bindings) {return and(condition(sql, bindings));}}

泛型和重載的麻煩

當(dāng)使用Eclipse開發(fā)時(shí)，Java 5世界似乎比實(shí)際情況更加光彩照人。 Varargs和泛型在Java 5中作為語法糖引入。它們在JVM中并不是真的存在。 這意味著編譯器必須正確鏈接方法調(diào)用，在需要時(shí)推斷類型，并在某些情況下創(chuàng)建綜合方法。 根據(jù)JLS（ Java語言規(guī)范 ），當(dāng)在重載方法中使用varargs / generics時(shí)，存在很多歧義。

讓我們詳細(xì)介紹一下泛型：

在jOOQ中要做的一件好事是將常量值與字段一樣對(duì)待。 在許多地方，字段參數(shù)像這樣重載：

// This is a convenience method:public static <T> Field<T> myFunction(Field<T> field, T value) {return myFunction(field, val(value));}// It's equivalent to this one.public static <T> Field<T> myFunction(Field<T> field, Field<T> value) {return MyFunction<T>(field, value);}

在大多數(shù)情況下，上面的方法效果很好。 您可以像這樣使用上述API：

Field<Integer> field1 = //...Field<String> field2 = //...Field<Integer> result1 = myFunction(field1, 1);Field<String> result2 = myFunction(field2, "abc");

但是，當(dāng)<T>綁定到對(duì)象時(shí)，就會(huì)出現(xiàn)麻煩！

// While this works...Field<Object> field3 = //...Field<Object> result3 = myFunction(field3, new Object());// ... this doesn't!Field<Object> field4 = //...Field<Object> result4 = myFunction(field4, field4);Field<Object> result4 = myFunction(field4, (Field) field4);Field<Object> result4 = myFunction(field4, (Field<Object>) field4);

當(dāng)<T>綁定到Object時(shí)，兩種方法突然都適用，并且根據(jù)JLS，它們都不是更具體的！ 盡管Eclipse編譯器通常比較寬容（并且在這種情況下直觀地鏈接了第二個(gè)方法），但是javac編譯器不知道該調(diào)用要做什么。 而且沒有辦法解決。 您不能將field4強(qiáng)制轉(zhuǎn)換為Field或Field <Object>強(qiáng)制鏈接器鏈接至第二種方法。 對(duì)于API設(shè)計(jì)人員來說，這是個(gè)壞消息。

有關(guān)此特殊情況的更多詳細(xì)信息，請(qǐng)考慮以下堆棧溢出問題，我將此問題報(bào)告給Oracle和Eclipse。 讓我們看看哪種編譯器實(shí)現(xiàn)是正確的：
http://stackoverflow.com/questions/5361513/reference-is-ambiguous-with-generics

靜態(tài)導(dǎo)入的麻煩，varargs

Varargs是Java 5中引入的另一個(gè)重要功能。盡管它只是語法糖，但在將數(shù)組傳遞給方法時(shí)可以節(jié)省很多代碼：

// Method declarations with or without varargspublic static String concat1(int[] values);public static String concat2(int... values);// The above methods are actually the same.String s1 = concat1(new int[] { 1, 2, 3 });String s2 = concat2(new int[] { 1, 2, 3 });// Only, concat2 can also be called like this, convenientlyString s3 = concat2(1, 2, 3);

那是眾所周知的。 它與原始類型數(shù)組的工作方式與與Object []相同。 它也可以與T []一起使用，其中T是泛型類型！

// You can now have a generic type in your varargs parameter:public static <T> T[] array(T... values);// The above can be called "type-safely" (with auto-boxing):Integer[] ints = array(1, 2, 3);String[] strings = array("1", "2", "3");// Since Object could also be inferred for T, you can even do this:Object[] applesAndOranges = array(1, "2", 3.0);

最后一個(gè)例子實(shí)際上已經(jīng)暗示了這個(gè)問題。 如果T沒有任何上限，則類型安全性完全消失。 這是一種錯(cuò)覺，因?yàn)樽詈?#xff0c;總是可以將varargs參數(shù)推斷為“ Object…”。 這就是當(dāng)您重載此類API時(shí)這會(huì)引起麻煩的方式。

// Overloaded for "convenience". Let's ignore the compiler warning// caused when calling the second methodpublic static <T> Field<T> myFunction(T... params);public static <T> Field<T> myFunction(Field<T>... params);

起初，這看起來是個(gè)好主意。 參數(shù)列表可以是常量值（T…）或動(dòng)態(tài)字段（Field…）。 因此，原則上，您可以執(zhí)行以下操作：

// The outer function can infer Integer for <T> from the inner// functions, which can infer Integer for <T> from T...Field<Integer> f1 = myFunction(myFunction(1), myFunction(2, 3));// But beware, this will compile too!Field<?> f2 = myFunction(myFunction(1), myFunction(2.0, 3.0));

內(nèi)部函數(shù)將推斷<T>的Integer和Double。 對(duì)于不兼容的返回類型Field <Integer>和Field <Double>，帶有“ Field <T>…”參數(shù)的“打算”方法不再適用。 因此，編譯器將帶有“ T…”的方法一鏈接為唯一適用的方法。 但是您不會(huì)猜測<T>的（可能）推斷范圍。 這些是可能的推斷類型：

// This one, you can always do:Field<?> f2 = myFunction(myFunction(1), myFunction(2.0, 3.0));// But these ones show what you're actually about to doField<? extends Field<?>> f3 = // ...Field<? extends Field<? extends Number>> f4 = // ...Field<? extends Field<? extends Comparable<?>>> f5 = // ...Field<? extends Field<? extends Serializable>> f6 = // ...

編譯器可以推斷出諸如Field <？ 將Number＆Comparable <？>和Serializable>擴(kuò)展為<T>的有效上限。 但是，<T>沒有有效的確切界限。 因此，必要的<？ 擴(kuò)展[上限]>。

結(jié)論

將varargs參數(shù)與泛型結(jié)合使用時(shí)要特別小心，尤其是在重載方法中。 如果用戶將通用類型參數(shù)正確綁定到您想要的目標(biāo)，則一切正常。 但是，如果有一個(gè)拼寫錯(cuò)誤（例如，將Integer與Double混淆），那么您的API用戶就注定了。 而且他們不會(huì)輕易發(fā)現(xiàn)自己的錯(cuò)誤，因?yàn)闆]有人能讀懂這樣的編譯器錯(cuò)誤消息：

Test.java:58: incompatible types found : Test.Field<Test.Field<? extends java.lang.Number&java.lang.Comparable<? extends java.lang.Number&java.lang.Comparable<?>>>> required: Test.Field<java.lang.Integer>Field<Integer> f2 = myFunction(myFunction(1),myFunction(2.0, 3.0));

參考：在JAVA，SQL和JOOQ博客上，我們的JCG合作伙伴 Lukas Eder 謹(jǐn)慎使用了重載API方法 。

相關(guān)文章 ：

• Java中的數(shù)據(jù)庫架構(gòu)導(dǎo)航
• ORM問題
• Java泛型快速教程
• 使用Spring和Java泛型簡化數(shù)據(jù)訪問層

翻譯自: https://www.javacodegeeks.com/2011/12/overload-api-methods-with-care.html

api中重載函數(shù)的原理

總結(jié)

以上是生活随笔為你收集整理的api中重载函数的原理_小心重载API方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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