Почему меня должно волновать, что в Java нет обобщенных дженериков?

Это возникло в качестве вопроса, который я недавно задал в интервью, поскольку кандидат хотел бы видеть добавление к языку Java. Обычно болью называют то, что в Java нет обобщенных дженериков, но, когда меня подталкивали, кандидат не мог сказать мне, чего бы он мог достичь, если бы они были там.

Очевидно, что из-за того, что в Java допустимы необработанные типы (и небезопасные проверки), можно разрушить обобщенные типы и получить в результате a, List<Integer>который (например) фактически содержит Strings. Очевидно, что это можно было бы сделать невозможным, если бы информация о типе была переработана; но должно быть нечто большее !

Могут ли люди публиковать примеры того, что они действительно хотели бы делать , если бы были доступны обобщенные дженерики? Я имею в виду, очевидно, что вы могли получить тип a Listво время выполнения - но что бы вы с ним сделали?

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

РЕДАКТИРОВАТЬ : быстрое обновление этого, поскольку ответы, похоже, в основном связаны с необходимостью передать a Classв качестве параметра (например EnumSet.noneOf(TimeUnit.class)). Я искал что-то вроде того, где это просто невозможно . Например:

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

Из тех нескольких раз, когда я сталкивался с этой «необходимостью», в конечном итоге она сводится к следующей конструкции:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

Это работает в C # при условии, что у Tнего есть конструктор по умолчанию . Вы даже можете получить тип среды выполнения typeof(T)и получить конструкторы Type.GetConstructor().

Распространенным решением Java было бы передать Class<T>аргумент as.

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

(его необязательно передавать в качестве аргумента конструктора, поскольку аргумент метода также подходит, приведенное выше является лишь примером, также try-catchопущено для краткости)

Для всех других конструкций универсального типа фактический тип может быть легко определен с небольшой помощью отражения. Приведенные ниже вопросы и ответы иллюстрируют варианты использования и возможности:

• Получить общий тип java.util.List
• Как получить универсальный тип во время выполнения?
• Получить фактический тип аргумента универсального типа в абстрактном суперклассе

Что меня чаще всего раздражает, так это невозможность использовать преимущества множественной диспетчеризации для нескольких универсальных типов. Следующее невозможно, и во многих случаях это было бы лучшим решением:

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

На ум приходит безопасность типов . Преобразование в параметризованный тип всегда будет небезопасным без обобщенных дженериков:

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

Кроме того, абстракции будут меньше просачиваться - по крайней мере, те, которые могут быть заинтересованы в информации времени выполнения об их параметрах типа. Сегодня, если вам нужна какая-либо информация времени выполнения о типе одного из общих параметров, вы также должны передать его Class. Таким образом, ваш внешний интерфейс зависит от вашей реализации (независимо от того, используете ли вы RTTI для своих параметров или нет).

Вы сможете создавать в своем коде универсальные массивы.

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

Это старый вопрос, на него есть масса ответов, но я думаю, что существующие ответы не соответствуют действительности.

«овеществленный» просто означает настоящий и обычно означает противоположность стирания шрифта.

Большая проблема, связанная с Java Generics:

• Это ужасное требование бокса и разрыв между примитивами и ссылочными типами. Это напрямую не связано с овеществлением или стиранием шрифта. C # / Scala исправит это.
• Никаких самотипов. По этой причине в JavaFX 8 пришлось удалить «строителей». Абсолютно никакого отношения к стиранию шрифта. Scala исправляет это, но не уверен в C #.
• Нет отклонения типа стороны объявления. В C # 4.0 / Scala это есть. Абсолютно никакого отношения к стиранию шрифта.
• Не может перегрузить void method(List<A> l)и method(List<B> l). Это происходит из-за стирания шрифта, но это очень мелочь.
• Нет поддержки для отражения типа во время выполнения. Это суть стирания шрифтов. Если вам нравятся суперсовременные компиляторы, которые проверяют и подтверждают как можно больше логики вашей программы во время компиляции, вам следует как можно меньше использовать отражение, и этот тип стирания типа не должен вас беспокоить. Если вам нравится более неоднородное, скриптовое, динамическое программирование типов и вы не очень заботитесь о том, чтобы компилятор проверял как можно большую часть вашей логики, тогда вам нужно лучшее отражение, и важно исправить стирание типов.

С овеществлением сериализация была бы более простой. Мы бы хотели

deserialize(thingy, List<Integer>.class);

Что нам нужно сделать

deserialize(thing, new TypeReference<List<Integer>>(){});

выглядит некрасиво и прикольно работает.

Бывают также случаи, когда было бы действительно полезно сказать что-то вроде

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

Эти штуки кусаются не часто, но кусаются, когда случаются.

Мое знакомство с Java Geneircs довольно ограничено, и помимо пунктов, которые уже упоминались в других ответах, есть сценарий, объясненный в книге Java Generics and Collections Морисом Нафталином и Филипом Уолдером, где овеществленные дженерики полезны.

Поскольку типы не реифицируемы, невозможно иметь параметризованные исключения.

Например, декларация формы ниже недействительна.

class ParametericException<T> extends Exception // compile error

Это связано с тем, что предложение catch проверяет, соответствует ли выброшенное исключение заданному типу. Эта проверка аналогична проверке, выполняемой тестом экземпляра, и, поскольку тип не подлежит повторной проверке, указанная выше форма оператора недействительна.

Если бы приведенный выше код был действителен, тогда была бы возможна обработка исключений следующим образом:

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

В книге также упоминается, что если общие шаблоны Java определены аналогично тому, как определены шаблоны C ++ (расширение), это может привести к более эффективной реализации, поскольку это дает больше возможностей для оптимизации. Но не предлагает никаких объяснений, кроме этого, поэтому любые объяснения (указатели) от знающих людей были бы полезны.

Массивы, вероятно, были бы намного лучше с дженериками, если бы они были преобразованы.

У меня есть оболочка, которая представляет набор результатов jdbc в качестве итератора (это означает, что я могу намного проще выполнять модульное тестирование операций, связанных с базой данных, с помощью внедрения зависимостей).

API выглядит как Iterator<T> T - это некоторый тип, который может быть построен с использованием только строк в конструкторе. Затем Iterator просматривает строки, возвращаемые из запроса sql, и затем пытается сопоставить их с конструктором типа T.

В текущем способе реализации дженериков я также должен передать класс объектов, которые я буду создавать из своего набора результатов. Если я правильно понимаю, если бы дженерики были реифицируются, я мог бы просто вызвать T.getClass (), чтобы получить его конструкторы, и тогда не пришлось бы приводить результат Class.newInstance (), что было бы намного аккуратнее.

В принципе, я думаю, что это упрощает написание API (в отличие от простого написания приложения), потому что вы можете сделать гораздо больше из объектов, и, следовательно, потребуется меньшая конфигурация ... Я не оценил значение аннотаций, пока я не видел, как они используются в таких вещах, как spring или xstream, а не в кучах config.

Приятно было бы избежать бокса для примитивных (значений) типов. Это в некоторой степени связано с жалобой на массивы, которую подняли другие, и в случаях, когда использование памяти ограничено, это может действительно иметь существенное значение.

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

Это не значит, что вы добьетесь чего-то экстраординарного. Просто будет проще понять. Стирание типов кажется трудным для новичков, и в конечном итоге требует понимания того, как работает компилятор.

Я считаю, что дженерики - это просто дополнение, которое избавляет от лишнего приведения типов.

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

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

Вот один, который меня поймал сегодня: без реификации, если вы напишете метод, который принимает список универсальных элементов varargs ... вызывающие могут ДУМАТЬ, что они безопасны по типу, но случайно передают любую старую грязь и взорвут ваш метод.

Кажется маловероятным, что это произойдет? ... Конечно, пока ... вы не используете Class в качестве типа данных. На этом этапе ваш вызывающий с радостью отправит вам множество объектов Class, но простая опечатка отправит вам объекты Class, которые не соответствуют T, и произойдет катастрофа.

(NB: я, возможно, ошибся здесь, но поискав в Google "generics varargs", вышеприведенное, похоже, именно то, что вы ожидаете. То, что делает это практической проблемой, - это использование Class, я думаю - вызывающие абоненты кажутся быть менее осторожным :()

Например, я использую парадигму, в которой объекты класса используются в качестве ключа на картах (это сложнее, чем простая карта, но концептуально именно это и происходит).

например, это отлично работает в Java Generics (тривиальный пример):

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

например, без повторения в Java Generics, этот принимает ЛЮБОЙ объект «Класс». И это лишь крошечное расширение предыдущего кода:

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

Вышеупомянутые методы должны быть записаны тысячи раз в отдельном проекте, поэтому вероятность человеческой ошибки становится высокой. Отладка ошибок оказывается "неинтересной". Я сейчас пытаюсь найти альтернативу, но не питаю особых надежд.