Коли для дженерики Java потрібні <? розширює T> замість <T> і чи є якийсь мінус перемикання?

З огляду на наступний приклад (використовуючи JUnit з математиками Hamcrest):

Map<String, Class<? extends Serializable>> expected = null;
Map<String, Class<java.util.Date>> result = null;
assertThat(result, is(expected));  

Це не компілюється з assertThatпідписом методу JUnit :

public static <T> void assertThat(T actual, Matcher<T> matcher)

Повідомлення про помилку компілятора:

Error:Error:line (102)cannot find symbol method
assertThat(java.util.Map<java.lang.String,java.lang.Class<java.util.Date>>,
org.hamcrest.Matcher<java.util.Map<java.lang.String,java.lang.Class
    <? extends java.io.Serializable>>>)

Однак якщо я зміню assertThatпідпис методу на:

public static <T> void assertThat(T result, Matcher<? extends T> matcher)

Потім компіляція працює.

Отже три питання:

1. Чому саме не збирається поточна версія? Хоча я тут невиразно розумію проблеми коваріації, я, звичайно, не міг пояснити це, якби це зробити.
2. Чи є якісь недоліки в зміні assertThatметоду на Matcher<? extends T>? Чи є інші випадки, які б розірвалися, якби ви це зробили?
3. Чи є якийсь сенс до генералізації assertThatметоду в JUnit? MatcherКлас , здається, не вимагає, оскільки JUnit викликає метод сірників, яка не надрукований з будь-якими родовими, і просто виглядає як спроба змусити типу безпеки , який нічого не робить, так як Matcherпросто не буде насправді збігаються, і тест вийде з ладу незалежно. Жодних небезпечних операцій (чи так здається).

Для довідки, ось реалізація JUnit assertThat:

public static <T> void assertThat(T actual, Matcher<T> matcher) {
    assertThat("", actual, matcher);
}

public static <T> void assertThat(String reason, T actual, Matcher<T> matcher) {
    if (!matcher.matches(actual)) {
        Description description = new StringDescription();
        description.appendText(reason);
        description.appendText("\nExpected: ");
        matcher.describeTo(description);
        description
            .appendText("\n     got: ")
            .appendValue(actual)
            .appendText("\n");

        throw new java.lang.AssertionError(description.toString());
    }
}

По-перше - я маю направити вас на http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html - вона робить дивовижну роботу.

Основна ідея, яку ви використовуєте

<T extends SomeClass>

коли фактичним параметром може бути SomeClassбудь-який його підтип.

У вашому прикладі

Map<String, Class<? extends Serializable>> expected = null;
Map<String, Class<java.util.Date>> result = null;
assertThat(result, is(expected));

Ви говорите, що expectedможе містити об'єкти Class, які представляють будь-який клас, який реалізує Serializable. На вашій карті результатів написано, що вона може містити лишеDate об'єкти класу.

Коли ви передаєте в результаті ви встановлюєте Tточно Mapз Stringдо Dateоб'єктів класу, які не відповідають Mapвід Stringні до чого , що це Serializable.

Одне, що потрібно перевірити - ти впевнений, що хочеш, Class<Date>а ні Date? Карта Stringдля Class<Date>загалом не здається страшно корисною (все, що вона вміє, - це Date.classяк значення, а не екземпляри Date)

Що стосується генеризації assertThat, то ідея полягає в тому, що метод може забезпечити передачу даних , Matcherщо відповідає типу результату.

Дякую всім, хто відповів на питання, це дійсно допомогло з’ясувати речі для мене. Врешті-решт відповідь Скотта Стенчфілда наблизилась до того, як я в кінцевому підсумку зрозумів це, але оскільки я не зрозумів його, коли він вперше написав це, я намагаюся відновити проблему, щоб, сподіваюся, хтось інший отримав користь.

Я збираюся повторно поставити запитання щодо списку, оскільки він має лише один загальний параметр, і це полегшить розуміння.

Мета параметризованого класу (наприклад, Список <Date>або Карта, <K, V>як у прикладі) - примусити знижувати обвал та надання компілятором гарантії, що це безпечно (без винятку з виконання).

Розглянемо випадок Списку. Суть мого питання полягає в тому, чому метод, який приймає тип T і List, не приймає Перелік чогось далі за ланцюгом успадкування, ніж Т. Розгляньте цей надуманий приклад:

List<java.util.Date> dateList = new ArrayList<java.util.Date>();
Serializable s = new String();
addGeneric(s, dateList);

....
private <T> void addGeneric(T element, List<T> list) {
    list.add(element);
}

Це не буде компілюватися, оскільки параметр list - це список дат, а не список рядків. Дженерики були б не дуже корисними, якби це було складено.

Те саме стосується Карти. <String, Class<? extends Serializable>>Це не те саме, що і Мапу <String, Class<java.util.Date>>. Вони не є коваріантними, тому, якщо я хотів взяти значення з карти, що містить класи дат, і помістити її в карту, що містить елементи, що серіалізуються, це добре, але підпис методу, який говорить:

private <T> void genericAdd(T value, List<T> list)

Хоче вміти робити і те, і інше:

T x = list.get(0);

і

list.add(value);

У цьому випадку, хоча метод junit насправді не стосується цих речей, підпис методу вимагає коваріації, якої він не отримує, тому не компілюється.

З другого питання:

Matcher<? extends T>

Було б недоліком дійсно прийняти що-небудь, коли T - це Об'єкт, що не має наміру API. Намір полягає в тому, щоб статично переконатися, що збірник відповідає фактичному об'єкту, і немає жодного способу виключити Об'єкт із цього обчислення.

Відповідь на третє запитання полягає в тому, що нічого не буде втрачено з точки зору неперевіреної функціональності (не було б небезпечного набору тексту в API JUnit, якби цей метод не був генералізований), але вони намагаються здійснити щось інше - статично гарантувати, що два параметри, ймовірно, збігаються.

EDIT (після подальшого розгляду та досвіду):

Однією з найважливіших проблем підпису методу assertThat є намагання зрівняти змінну T із загальним параметром T. Це не працює, оскільки вони не є коваріантними. Так, наприклад, у вас може бути T, який є, List<String>але потім передайте збіг, на який працює компілятор Matcher<ArrayList<T>>. Тепер, якщо це не параметр типу, все було б добре, тому що List і ArrayList є коваріантними, але оскільки Generics, що стосується компілятора, вимагає ArrayList, він не може терпіти список з причин, на які я сподіваюся, зрозумілі з вище сказаного.

Він зводиться до:

Class<? extends Serializable> c1 = null;
Class<java.util.Date> d1 = null;
c1 = d1; // compiles
d1 = c1; // wont compile - would require cast to Date

Ви можете бачити, що посилання класу c1 може містити екземпляр Long (оскільки базовий об'єкт в даний момент міг бути List<Long>), але очевидно, не може бути передано дату, оскільки немає гарантії, що "невідомий" клас був Date. Це не безпечно, тому компілятор відключає це.

Однак, якщо ми введемо якийсь інший об'єкт, скажімо, Список (у вашому прикладі цей об'єкт є Матчер), то наступне стане істинним:

List<Class<? extends Serializable>> l1 = null;
List<Class<java.util.Date>> l2 = null;
l1 = l2; // wont compile
l2 = l1; // wont compile

... Однак якщо тип списку стає? розширює T замість T ....

List<? extends Class<? extends Serializable>> l1 = null;
List<? extends Class<java.util.Date>> l2 = null;
l1 = l2; // compiles
l2 = l1; // won't compile

Я думаю, змінившись Matcher<T> to Matcher<? extends T>, ви в основному представляєте сценарій, аналогічний призначенню l1 = l2;

Це все ще дуже заплутано, коли вкладені підстановки, але, сподіваємось, це має сенс, чому це допомагає зрозуміти дженерики, дивлячись на те, як можна призначати загальні посилання один одному. Це також додатково заплутано, оскільки компілятор підводить тип T під час виклику функції (ви прямо не говорите, що це T є).

Причина, по якій ваш початковий код не компілюється, полягає в тому, що <? extends Serializable>це не означає "будь-який клас, який розширює Serializable", а "якийсь невідомий, але конкретний клас, який розширює Serializable".

Наприклад, якщо код , як написано, це цілком допустимо призначати new TreeMap<String, Long.class>()>в expected. Якби компілятор дозволив компілювати код, assertThat()він, ймовірно, зламається, оскільки очікував би Dateоб'єктів замість Longоб'єктів, які він знайде на карті.

Один із способів мені зрозуміти макіяж - це думати, що підстановочний код не вказує тип можливих об'єктів, на які може бути "загальна посилання", а тип інших загальних посилань, з якими він сумісний (це може здатися заплутаним) ...) Як така, перша відповідь є дуже оманливою в її формулюванні.

Іншими словами, List<? extends Serializable>означає, що ви можете призначити це посилання іншим Спискам, де тип - якийсь невідомий тип, який є або підкласом Serializable. НЕ думайте про це з точки зору того, що ЄДИННИЙ СПИСОК зможе містити підкласи Serializable (адже це неправильна семантика і призводить до нерозуміння Generics).

Я знаю, що це давнє запитання, але я хочу поділитися прикладом, який, на мою думку, досить добре пояснює обмежені символи. java.util.Collectionsпропонує цей метод:

public static <T> void sort(List<T> list, Comparator<? super T> c) {
    list.sort(c);
}

Якщо у нас є Список T, Список, звичайно, може містити екземпляри типів, які розширюються T. Якщо у списку містяться тварини, у списку можуть бути як собаки, так і кішки (обидві тварини). Собаки мають властивість "woofVolume", а коти мають властивість "meowVolume". Хоча ми можемо хотіти сортувати на основі цих властивостей, зокрема, підкласи T, як ми можемо розраховувати, що цей спосіб це зробить? Обмеження компаратора в тому, що він може порівнювати лише дві речі лише одного типу ( T). Отже, вимагаючи просто а Comparator<T>, цей метод зробить корисним. Але творець цього методу визнав, що якщо щось є T, то це також екземпляр суперкласів T. Тому він дозволяє використовувати компаратор Tбудь-якого суперкласу T, тобто ? super T.

що робити, якщо ви використовуєте

Map<String, ? extends Class<? extends Serializable>> expected = null;