Java的子類或實現泛型類型相同的邊界

Question

我的問題是，在短，是否給予

interface Intf<T extends Bound> {} 
class Clss<T extends Bound> {} 

是有沒有辦法繼承/實現不是重複綁定的類型他們的其他：

class Impl<T extends Bound> implements Intf<T> {} 
class Subc<T extends Bound> extends Clss<T> {} 

我不是抱怨需要重複extends Bound，我甚至理解編譯器邏輯，但我想知道這是否真的是這樣。因爲在兩個地方使用<T>在語義上對我來說足夠了。

Answer 1

是的，就是這樣。爲了大家的緣故，這裏是完整的解釋。

這裏就是你們的榜樣的另一個版本（想象整型可擴展）

interface Intf<T extends Number> {} 
class Clss<T extends Number> {} 
class Impl<T extends Integer> implements Intf<T> {} 
class Subc<T extends Integer> extends Clss<T> {} 
class ImplSubc<T extends Integer> extends Clss<T> implements Intf<T> {} 

的<T extends Integer>是初始化標籤，以及進一步<T>標籤基本上都是「傳遞下去」的引用。這兩個標籤在視覺上是相同的，但它們是不同的東西。由於沿標記通需要別的東西來初始化請注意以下內容是非法的

class Subc<T extends Integer> extends Clss<T extends Integer> {} 

。所以你可以知道哪些是因爲initialize標籤最終會傳遞給它，而傳遞標籤是根據初始化標籤設置的內容傳遞（或返回）的東西。所以，如果你只有以下幾種：

class Subc<T> extends Clss<T> {} 

編譯單元說：「允許它被設置爲任何東西，並將其傳遞給Clss」。由於您可以將初始化標記傳遞給多個傳遞標記，每個傳遞標記都可能具有不同的邊界，因此需要明確設置初始化標記NEEDS以確保傳遞的<T>確實與您傳遞的所有內容都兼容。雖然這在技術上可以推斷出來，但它昂貴，複雜，並要求可怕的生產破壞錯誤，所以編譯器只會迫使你知道你在做什麼。

更新：
這裏是一個例子，說明如果讓編譯器決定你的代碼是什麼，一個bug如何進入生產。假設編譯器並推斷限制，如果

class Clss<T extends Number> {} 
class Subc<T> extends Clss<T> {} 

成爲

class Clss<T extends BigDecimal> {} 
class Subc<T> extends Clss<T> {} 

沒有extends Integer集上SUBC，讓它可以推斷，這種變化將彙編（如果這是根據在什麼使用它作爲一個獨立的API），並且可能仍然在工作，直到它沒有。因爲你說你明確想要使用Integer或Number，所以現在可以在編譯時確定更改Clss的類型是安全的還是壞的更改，而不是運行時。 Java是安全第一類型語言，這意味着代碼穩定性/可靠性檢測是其特性的核心價值。所以如果有疑問，Java會抱怨。

Answer 2

請注意，雖然Foo<T [constraints]> implements Bar<T>模式非常常見，但它只有一種可能性。這裏有一些人（非詳盡）：

Foo<T extends DerivedBound>  implements Bar<T> 
Foo<T>        implements Bar<DerivedBound> 
Foo<T>        implements Bar<ParameterisedBound<T>> 
Foo<T, U extends Bound>   implements Bar<U> 
Foo<T extends BarBound & BazBound> implements Bar<T>, Baz<T> 

所以這是在其指定的約束兩次沒有冗餘 - 信息你提供兩個獨立的部件來編譯。

從理論上講，語言設計者可以爲Java添加一個特例，以節省一些字符。但假設他們甚至考慮過這個選擇，我想他們認爲額外的複雜性不是一個好的折衷。