Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>17 ноя 2021</li>

3 <li>0</li>

4 </ul>Рассказываем, как в любой непонятной ситуации правильно сочетать дженерик-типы.

5 Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.

6 В предыдущей статье "<a>Дженерики для самых маленьких</a>" мы рассказали о том, что такое дженерики (generics), зачем они нужны и как создавать дженерик-типы и методы. Там же говорили про ограничения (boundings) и wildcards. Без этих основ вам будет сложно разобраться с тем, что написано дальше. Поэтому освежите знания, если это необходимо.

7 Из этой статьи вы узнаете:

8 <ul><li><a>почему ни один дженерик не доживает до выполнения программы</a>;</li>

9 <li><a>как создать наследника дженерик-класса</a>;</li>

10 <li><a>что не так с дженерик-типами классов-наследников</a>;</li>

11 <li><a>как переопределить метод с дженерик-типами</a>;</li>

12 <li><a>как wildcards с ограничениями "портят" коллекции и зачем нужен принцип PECS</a>.</li>

13 </ul>Воспользуемся примером из первой части рассказа о дженериках: там был класс Box<T> - коробка для сбора мусора: можно было положить в неё или извлечь из неё только объект определённого типа:

14 class Box<T> { // обозначение типа - T // переменная с типом T private T item; public void putItem(T item) { // параметр метода типа T this.item = item; } public T getItem() { // возвращает объект типа T return item; } }Теперь создадим экземпляр такого класса и подставим вместо T конкретный тип: например, Paper - для коробки, в которую будем собирать бумагу:

15 class Paper {} Box<Paper> boxForPaper = new Box<Paper>();Можно предположить, что теперь мы имеем дело с таким классом:

16 class Box<Paper> { private Paper item; public void putItem(Paper item) { this.item = item; } public Paper getItem() { return item; } }Эта запись помогает понять, как класс будет работать, но она не имеет ничего общего с тем, во чтопревращаетсядженерик-класс или интерфейс в результате компиляции.

17 Компилятор не генерирует class-файл длякаждогопараметризованного типа. Он создаётодинclass-файл для дженерик-типа.

18 Компилятор стирает информацию о типе, заменяя все параметры без ограничений (unbounded) типом Object, а параметры с границами (bounded) - на эти границы. Это называетсяtype erasure.

19 Кроме стирания (иногда говорят "затирания") типов, компилятор может добавлять приведение (cast) к нужному типу и создавать переходные bridge-методы, чтобы сохранить полиморфизм в классах-наследниках.

20 Пример 1. Стирание типа для дженерика без границ

21 Все параметры типов заменяются на Object. Вот что получится для нашего класса-коробки:

22 class Box { private Object item; public void putItem(Object item) { this.item = item; } public Object getItem() { return item; } }Пример 2. Стирание типа для дженерика с границами

23 Объявим дженерик-интерфейс c ограничением сверху (upper bounding):

24 interface BoxMap<K extends Box, V>{ void put(K key, V value); V get(K key); }Вот что от этого останется после компиляции:

25 interface BoxMap{ void put(Box key, Object value); Object get(Box key); }Пример 3. Bridge-метод

26 Создадим класс-наследник коробки для бумаги и переопределим в нём метод putItem:

27 class CoolPaperBox extends Box<Paper>{ public void putItem(Paper item) { super.putItem(item); } }Этому классу не всё равно, какого типа объекты приходят к нему в putItem, - нужно, чтобы они были типа Paper. Поэтому компилятору придётся немного докрутить класс - добавить в него bridge-метод с приведением типа:

28 class CoolPaperBox extends Box<Paper>{ public void putItem(Paper item) { super.putItem(item); } // это и есть bridge-метод public void putItem(Object item) { putItem((Paper)item); } }А вот ещё несколько примеров дженерик-типов и того, что от них останется после компиляции:

29 До компиляцииПосле компиляции<T extends Box<T>>Box<? super Box>BoxList<Box>[]List[]Из-за стирания типов при выполнении программы точно не известно, какойконкретнотип будет иметь экземпляр дженерик-класса. Единственное исключение - дженерик с wildcard без ограничений, например List<?>. Такой список будет считаться List<Object>.

30 Теперь, когда вы знаете проtype erasureи его последствия, наверняка сможете ответить на вопрос, почему нельзя создать дженерик-Exception:

31 class GenericException<T> extends Exception { // не скомпилируется }Ответ:

32 В каждом блокеtrycatchпроверяется тип исключения, так как разные типы исключений могут обрабатываться по-разному. Для дженерик-исключения определить конкретный тип было бы невозможно, а потому компилятор даже не даст его создать. Это правило относится к классу Throwable и его наследникам.

33 Наследник дженерик-класса может быть дженериком или обычным классом. Это зависит от того, как обращаться с параметрами типа родителя. Разберём три примера со знакомым нам Box<T>.

34 Пример 1.Класс-наследник - не дженерик.

35 public class SuperNonGenericBox extends Box<Paper> { }Чтобы получить обычный, не дженерик-класс, мы должны вместо параметра T передать какой-то конкретный тип, что мы и сделали - передали Paper.

36 Пример 2.Класс-наследник и сам дженерик с тем же числом параметров.

37 public class SuperGenericBox<T> extends Box<T> { }Параметры у Box и SuperGenericBox не обязаны обозначаться буквой T (от type) - можно брать любую. В этом примере важно, чтобы буквы были одинаковые, иначе компилятор не разберётся.

38 Пример 3.Класс-наследник - дженерик с другим числом параметров.

39 public class SuperDoubleGenericBox<T, V> extends Box<T> { public void newMethod(V param) { // здесь что-то происходит } }Здесь уже не один, а два параметра. Один передадим родителю, а второй используем как-нибудь ещё - например, напишем метод newMethod с параметром этого нового типа.

40 У наследника класса-дженерика может быть сколько угодно параметров, включая ноль (когда это вовсе не дженерик). Главное - помнить про все параметры типа родительского класса и передать для каждого параметра конкретный тип или какой-то из параметров класса-наследника.

41 В Java можно присвоить объект одного типа объекту другого типа, если типы совместимы: реализуют один и тот же интерфейс или лежат в одной цепочке наследования.

42 Например, PaperBox - наследник Box, и пример ниже успешно компилируется:

43 class Box{} class PaperBox extends Box{} class Test{ Box box = new PaperBox(); }В терминах объектно-ориентированного программирования это называют отношениемis a(является): бумажная коробка - это коробка (является коробкой). Или говорят, что PaperBox - этоподтип(subtype) Box. При этом Box -супертипPaperBox.

44 Теперь возьмём не простую коробку, а её дженерик-вариант (Box<T>), в которую будем класть разные типы мусора: Paper, Glass и тому подобные типы - наследники Garbage:

45 class Garbage{} class Paper extends Garbage{} class Glass extends Garbage{} class Box<T extends Garbage> { // методы класса }В этом случае в качестве аргумента типа можно выбрать как Garbage, так и его подтип:

46 Box<Garbage> box = new Box<>(); box.putItem(new Garbage()); // успешно компилируется box.putItem(new Paper()); // успешно компилируетсяНо что, если Box<Garbage> станет типом параметра метода? Сможем ли мы в этом случае передать другой дженерик-тип? Напишем простой пример:

47 public void handle(Box<Garbage> box) { // что-то делаем с коробкой } public void test() { handle(new Box<Paper>()); // не скомпилируется }И убедимся, что замена тут не пройдёт. Несмотря на то что Paper - подтип Garbage, Box<Paper> -неподтип Box<Garbage>.

48 Дженерики инвариантны. Это означает, что, даже если A - подтип B, дженерик от A не является подтипом дженерика от B.

49 Для сравнения, массивы в Java ковариантны: если A - подтип B, A[] - подтип B[].

50 Несмотря на то что Paper - наследник Garbage, Box<Paper> - не наследник Box<Garbage>. Они оба наследники Object. Инфографика: Екатерина Степанова / Skillbox MediaПотренируемся сначала на простых типах и вспомним, что при переопределении методов необязательно полностью повторять сигнатуру родительского метода. Например, у таких методов могут различаться типы возвращаемых значений.

51 Переопределение будет правильным, если тип переопределённого метода - это подтип исходного метода. Например, так:

52 class Box { public Garbage doSomething() { return new Garbage(); } } class PaperBox extends Box { // корректное переопределение, т. к. Paper - подтип Garbage @Override public Paper doSomething() { return (Paper) super.doSomething(); } }Добавим немного дженериков и применим то же правило:

53 class Box { public List<Garbage> doSomething() { return Collections.emptyList(); } } class PaperBox extends Box { // корректное переопределение, // т. к. ArrayList<Garbage> - подтип List<Garbage> @Override public ArrayList<Garbage> doSomething() { return (ArrayList<Garbage>) super.doSomething(); } }Дженерики добавляют ещё пару возможностей для корректного переопределения. Оно будет верным, если:

54 <ul><li>переопределённый метод возвращает значение сырого (raw) типа от дженерик-типа, возвращаемого исходным методом;</li>

55 <li>переопределённый метод возвращает значение сырого (raw) типа от наследникадженерик-типа, возвращаемого исходным методом.</li>

56 </ul>Звучит сложно, так что лучше взглянем на код:

57 class Box { public List<Garbage> doSomething() { return Collections.emptyList(); } } class PaperBox extends Box { // корректное переопределение, // т. к. мы взяли raw-type от List<Garbage> @Override public List doSomething() { return super.doSomething(); } } class GlassBox extends Box { // корректное переопределение, т. к. мы взяли // raw-type от ArrayList<Garbage> - наследника List<Garbage> @Override public ArrayList doSomething() { return (ArrayList) super.doSomething(); } }Правда, в обоих случаях компилятор покажет предупреждение о небезопасном использовании типов (unchecked warning):

58 Note: GlassBox.java uses unchecked or unsafe operations.

59 Его можно понять: исходный метод требует, чтобы возвращался список объектов типа Garbage, а переопределённые хотят просто какой-то список. Там могут быть объекты типа Garbage, а могут и любые другие - вот компилятору и тревожно.

60 Зато если в исходном методе возвращаемый тип - с wildcard без ограничений, то при аналогичном переопределении предупреждений не будет:

61 class Box { public List<?> doSomething() { return Collections.emptyList(); } } class PaperBox extends Box { // корректное переопределение, // и никаких unchecked warnings @Override public List doSomething() { return super.doSomething(); } }При переопределении дженерик-методов с одинаковым числом параметров типа можно произвольно менять обозначения этих параметров:

62 class Box { public <T> void doSomething(T item) { // здесь что-то происходит } } class SuperBox extends Box { @Override public <S> void doSomething(S item) { // здесь что-то происходит } }В переопределённом методе параметр типа назван S, а не T, но переопределение остаётся корректным.

63 А вот ограничения для дженерика в переопределённом методе добавлять нельзя:

64 class SuperBox extends Box { @Override // не скомпилируется, так как это НЕ переопределение public <S extends Paper> void genericMethod(S item) { // здесь что-то происходит } }Получился не переопределённый метод, а просто метод с таким же названием.

65 Зато можно из дженерик-метода сделать обычный метод:

66 class SuperBox extends Box { @Override public void genericMethod(Object item) { // здесь что-то происходит } }Компилятор спокоен, потому что метод в классе Box станет именно таким после type erasure - параметр типа будет заменён на Object.

67 Переопределение дженерик-метода будет корректно, если:

68 <ul><li>сигнатуры методов в классе-родителе и классе-наследнике совпадают или различаются с точностью до обозначений параметров типа;</li>

69 <li>тип результата переопределённого метода - подтип для типа результата исходного метода;</li>

70 <li>переопределённый метод возвращает raw-type типа результата исходного метода или его подтип;</li>

71 <li>сигнатуры методов будут совпадать после type erasure.</li>

72 </ul>Если нужно что-то сделать с коллекциями объектов нескольких подтипов, удобны wildcards с ограничениями.

73 Например: List<? extends Paper> означает, что список может состоять из объектов типа Paper и всех его подтипов, а в List<? super Paper> могут быть объекты типа Paper и всех супертипов - например, Garbage или Object.

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

75 PECS - Producer Extends, Consumer Super. Его суть:

76 <ul><li>Коллекции с wildcards и ключевым словомextends - этоproducers(производители, генераторы), они лишь предоставляют данные.</li>

77 <li>Коллекции с wildcards и ключевым словомsuper - этоconsumers(потребители), они принимают данные, но не отдают их.</li>

78 </ul>Получается, в коллекцию с extends нельзя добавлять, а из коллекции с super нельзя читать? Вроде бы всё понятно, но давайте проверим:

79 List<? super Garbage>> list = new ArrayList<>();Попробуем положить сюда экземпляр Paper - наследника Garbage:

80 list.add(new Paper()); // не скомпилируетсяПолучим ошибку компиляции. Ладно, тогда, может, хотя бы объект типа Garbage подойдёт?

81 list.add(new Garbage()); // не скомпилируетсяИ снова нет. Принцип PECS не соврал - объект в такой список добавить нельзя. Единственное исключение - null. Вот так можно:

82 list.add(null); // OKС первой частью принципа разобрались, теперь создадим коллекцию с ограничением снизу:

83 List<? super Paper> list = new ArrayList<>();Добавим туда один объект типа Paper:

84 list.add(new Paper());И попробуем его же прочитать. Если верить PECS, у нас это не должно получиться:

85 list.get(0); //OKНо компилятору всё нравится - никаких ошибок нет. Проблемы, впрочем, начнутся, когда мы захотим сохранить полученное значение в переменной типа Paper или типа, совместимого с ним:

86 Paper p = list.get(0); // не скомпилируетсяВторая часть принципа PECS означает, что из коллекций, ограниченных снизу, нельзя без явного приведения типа (cast) прочитать объекты граничного класса, да и всех его родителей тоже. Единственное, что доступно, - тип Object:

87 Object p = list.get(0); // OKК сожалению, принцип PECS ничего не говорит о том, какие объекты можно читать из producer, а какие добавлять в customer. Мы не придумали своего принципа, но сделали табличку, чтобы собрать вместе все правила:

88 Тип ограниченияЧто можно читатьЧто можно записывать<?extendsSomeType>Объекты SomeType и всех его супертиповТолько null<?superSomeType>Объекты типа ObjectОбъекты типа SomeType и всех его подтиповИ сводный пример:

89 class Garbage {} class Paper extends Garbage {} class CoolPaper extends Paper{} public void testUpperBounding(List<? extends Paper> list){ Paper p = list.get(0); // OK Garbage g = list.get(1); // OK CoolPaper sp = list.get(2); // не скомпилируется list.add(new Paper()); // не скомпилируется list.add(null); // OK } public void testLowBounding(List<? super Paper> list){ Paper p = list.get(0); // не скомпилируется Garbage g = list.get(1); // не скомпилируется Object o = list.get(2); // OK list.add(new Garbage()); // не скомпилируется list.add(new Paper()); // OK list.add(new CoolPaper()); // OK }И даже картинку нарисовали:

90 Какие типы можно читать из коллекции с ограниченными wildcards и записывать в неё.Инфографика: Екатерина Степанова / Skillbox MediaТеперь точно не запутаетесь :)

91 Ещё больше хитростей дженериков и других особенностей Java - на курсе "<a>Профессия Java-разработчик</a>". Научим программировать на самом востребованном языке и поможем устроиться на работу.

92 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>