2013-08-01 4 views
7

Предположим, что у нас есть два общих интерфейса Java: Foo<T> и Bar<T>, из которых может быть много реализаций. Теперь предположим, что мы хотим, чтобы сохранить один из каждого в одном классе, и с использованием того же значения для T, но сохранить точные реализации напечатал:Java: Установление корреляций между параметрами типа

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

Выше T используется исключительно в целях обеспечения соблюдения, что Классы TFoo и TBar используют один и тот же параметр. Добавление этого параметра типа в FooBar представляется излишним по двум причинам:

  1. FooBar фактически не заботится о T вообще.
  2. Даже если бы это было так, T можно сделать с TFoo и TBar.

Таким образом, мой вопрос заключается в том, что существует способ принудительного соблюдения таких условий без загромождения списка параметров типа FooBar. Необходимо написать FooBar<String, StringFoo, StringBar> вместо теоретически эквивалент FooBar<StringFoo, StringBar> выглядит уродливым для меня.

+0

Как примечание стороны, я хотел бы видеть их, добавив синтаксис, похожий на 'публичный интерфейс FooBar , TBAR расширяет Бар > {}' на Java. – Smallhacker

+0

Я не думаю, что это возможно. Не с 'T' является общим. Большой вопрос +1 –

+0

Возможный дубликат [Резервные общие параметры] (http://stackoverflow.com/questions/9684186/redundant-generic-parameters) –

ответ

2

К сожалению, нет лучшего способа ... Компилятору нужен тип T, который был объявлен для того, чтобы использовать его и нет другого места, чтобы объявить:

EDIT: несвязанный ссылка

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)

И это немного не по теме, но this doc определяет условные обозначения имен параметров типа как одиночные, заглавные буквы.

+1

Хотя я не оспариваю то, что вы делаете, я просто хотел бы указать на запись, что связанный документ, похоже, не затрагивает ничего похожего на это. Кроме того, ваша цитата говорит о упорядочении классов и интерфейсов в границах, а не о том, объявлены они или нет. – Smallhacker

+0

Вы правы, связанный документ в основном не посвящен теме, поэтому наличие цитаты (отредактировано, чтобы сделать ее более понятной). И да, заказ упоминается, но в чем разница между «не указанными первым» и просто «не указан»? – gtinon

+0

Точка, к которой пытается попытаться документ, заключается в том, что классы должны быть указаны перед интерфейсами в выражении extends. Цитата может показаться актуальной, если ее вывести из контекста, но в контексте она не имеет ничего общего с этой темой. – Smallhacker

Смежные вопросы