2013-08-01 9 views
7

Załóżmy, że mamy dwa ogólne interfejsy Java: Foo<T> i Bar<T>, z których może istnieć wiele implementacji. Teraz załóżmy, że chcemy zapisać jednym z każdego w jednej klasie, zarówno przy użyciu tej samej wartości dla T, ale zachować dokładne implementacje wpisane:Java: Ustalanie korelacji między parametrami typu

public interface FooBar<T, TFoo extends Foo<T>, TBar extends Bar<T>> { 
    TFoo getFoo(); 
    TBar getBar(); 
} 

Powyżej T służy wyłącznie do celów egzekwowania że Klasy TFoo i TBar używają tego samego parametru typu. Dodanie tego parametru typu do FooBar wydaje się zbędne dla dwóch powodów:

  1. FooBar rzeczywistości nie dbają o T w ogóle.
  2. Nawet jeśli tak, T można wywnioskować z TFoo i TBar.

Moje pytanie brzmi zatem, czy istnieje sposób na egzekwowanie warunków takich jak ten bez zbędnej listy parametrów typu FooBar. Mając do napisania FooBar<String, StringFoo, StringBar> zamiast teoretycznie równowartość FooBar<StringFoo, StringBar> wygląda brzydko do mnie.

+0

Na marginesie, chciałbym zobaczyć ich dodanie składnię podobną do 'publicznego interfejsu foobar , TBar rozciąga Bar > {}' Java. – Smallhacker

+0

Nie sądzę, że to jest możliwe. Nie przy "T" jako ogólnym. Świetne pytanie +1 –

+0

możliwy duplikat [Nadmiarowe parametry ogólne] (http://stackoverflow.com/questions/9684186/redundant-generic-parameters) –

Odpowiedz

2

Niestety, nie ma lepszego sposobu ... Kompilator musi typu T do zgłoszenia w celu wykorzystania go i nie ma innego miejsca, aby ją zadeklarować:

EDIT: niepowiązanych odnośnik

If bound A is not specified first, you get a compile-time error:

class D <T extends B & A & C> { /* ... */ } // compile-time error 

(extract from this doc)

Jest to nieco poza tematem, ale this doc definiuje konwencje na nazwach parametrów typów jako pojedyncze, wielkie litery.

+1

Chociaż nie kwestionuję tego, co robisz, chciałbym tylko zwrócić uwagę na fakt, że dokument powiązany nie odnosi się do niczego podobnego do tego. Również twój cytat mówi o porządku klas i interfejsów w granicach, a nie o tym, czy zostały one zadeklarowane. – Smallhacker

+0

Masz rację, połączony dokument nie jest przede wszystkim poświęcony temu tematowi, stąd obecność cytatu (zredagowane, aby było nieco jaśniejsze). I tak, zamawiający jest wymieniony, ale jaka jest różnica między "nieokreślonym pierwszym" i po prostu "nieokreślonym"? – gtinon

+0

Punkt, do którego doc próbuje przejść, to fakt, że klasy muszą być określone przed interfejsami w instrukcji extends. Cytat może wydawać się odpowiedni, gdy zostanie usunięty z kontekstu, ale w kontekście nie ma nic wspólnego z tym tematem. – Smallhacker