Дженерики в Java для самых маленьких: синтаксис, границы и дикие карты

Знакомимся с дженериками

До появления дженериков программисты могли неявно предполагать, что какой-то класс, интерфейс или метод работает с элементами определённого типа.

Посмотрите на этот фрагмент кода:

public static void printSomething(List list){

   for (int i = 0; i < list.size(); i++){
       String item = (String)list.get(i);
       System.out.println(String.format("Длина строки \"%1$s\" = %2$d", item, item.length()));
   }
}

Здесь предполагается, что метод printSomething работает со списком строк. Мы можем догадаться об этом, потому что в цикле все элементы приводятся (преобразуются) к классу String, а потом ещё и метод length этого класса вызывается.

Но смотрите, что сделали программисты Саша и Маша, — они поленились заглянуть внутрь метода и положили в список: один — число, а вторая — экземпляр StringBuilder.

Вот только тестировщик назначил баг не кому-то из них, а Паше, который написал метод printSomething, — потому что ошибка произошла именно во время его выполнения.

Паша быстро нашёл истинных виновников и попросил их исправить заполнение списка. Но на будущее решил подстраховаться от подобных ситуаций и переписал метод с использованием дженериков. Вот так:

public static void printSomething(List<String> list) {

   for (int i = 0; i < list.size(); i++) {
       String item = list.get(i);
       System.out.println(String.format("Длина строки \"%1$s\" = %2$d", item, item.length()));
   }
}

Теперь, если кто-то захочет положить в массив нестроковый элемент, ошибка станет заметной сразу — ещё на этапе компиляции.

Обратите внимание, что во второй версии Пашиного метода item не приводится насильно к типу String. Мы просто получаем в цикле очередной элемент списка, и компилятор соглашается, что это, очевидно, будет строка. Код стал менее громоздким, читать его стало проще.

Объявляем дженерик-классы и создаём их экземпляры

Давайте запрограммируем ту самую коробку, о которой шла речь в начале статьи: создадим класс Box, который умеет работать только с элементами определённого типа. Пусть для простоты в этой коробке пока будет только один элемент:

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, а значит, экземпляр правильной коробки создаётся вот так:

class Paper {}
Box<Paper> boxForPaper = new Box<Paper>();

Это полный вариант записи, но можно и короче:

Box<Paper> boxForPaper = new Box<>();

Так как слева мы уже показали компилятору, что нужна коробка именно для бумаги, справа можно опустить повторное упоминание Paper — компилятор «догадается» о нём сам.

Это «угадывание» называется type inference — выведение типа, а оператор «<>» — это diamond operator. Его так назвали из-за внешнего сходства с бриллиантом.

Дженерик-классы хороши своей универсальностью: с классом Box теперь можно создать не только коробку для бумаги, но и, например, коробки для сбора пластика или стекла:

class Plastic {}
class Glass {}
Box<Plastic> boxForPlastic = new Box<>();
Box<Glass> boxForGlass = new Box<>();

А можно пойти ещё дальше и создать дженерик-класс с двумя параметрами для коробки с двумя отсеками. Вот так:

class TwoCellsBox<T, S> {
   private T firstCellItem;
   private S secondCellItem;
   //...
}

Теперь легко запрограммировать коробку, в одном отсеке которой будет собираться пластик, а во втором — стекло:

TwoCellsBox<Plastic, Glass> plasticGlassBox = new TwoCellsBox<>();

Обратите внимание, что type inference и diamond operator позволяют нам опустить оба параметра в правой части.

Объявляем и реализуем дженерик-интерфейсы

Объявление дженерик- интерфейсов похоже на объявление дженерик-классов. Продолжим тему переработки и создадим интерфейс пункта переработки GarbageHandler сразу с двумя параметрами: тип мусора и способ переработки:

interface GarbageHandler<T, S> {
   void handle(T what, S how);
}

Реализовать (имплементить) этот интерфейс можно в обычном, не дженерик- классе:

class MyPaperHandleMethod {
}

class MyNonGenericPaperHandler implements GarbageHandler<Paper, MyPaperHandleMethod> {
   @Override
   public void handle(Paper what, MyPaperHandleMethod how) {
       // здесь что-то делается с бумажным мусором способом MyPaperHandleMethod

   }
}

Но можно пойти другим путём и сначала объявить дженерик-класс с двумя параметрами:

class GarbageHandlerImpl<T, S> implements GarbageHandler<T, S> {
   @Override
   public void handle(T what, S how) {
       // здесь что-то делается с мусором типа T способом S
   }
}

Или скомбинировать эти два способа и написать дженерик-класс только с одним параметром:

class PaperHandler<T> implements GarbageHandler<Paper, T> {
   @Override
   public void handle(Paper what, T how) {
       // здесь что-то делается с бумагой способом T   
   }
}

Можно создавать экземпляры дженерик-типов «без расшифровки», то есть никто не запретит вам объявить переменную типа Box — просто Box:

Box box = new Box<>();

Для такого случая даже есть термин — raw type, то есть «сырой тип». Эту возможность оставили в языке для совместимости со старым кодом, который был написан до появления дженериков.

В новых программах так писать не рекомендуется. Да и зачем? Ведь при таком способе теряются все преимущества использования дженериков.

Пишем дженерик-методы

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

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

interface GarbageHandler<T, S> {
   void handle(T what, S how);

   <E> void transfer(E dangerousWaste);
}

У метода transfer есть свой личный параметр для типа, который не обязан совпадать ни с типом T, ни с типом S. При первом упоминании новый параметр, как и в случае с заголовком класса или интерфейса, пишется в угловых скобках.

Дженерик-методы можно объявлять и в обычных (не дженерик) классах и интерфейсах. Наш класс для переработки мог быть выглядеть так:

class GarbageHandlerImpl {

   public <T, S> void handle(T what, S how) {
       // здесь что-то делается с мусором типа T способом S
   }
}

Здесь дженерики используются только в методе.

Ограничиваем дженерики сверху и снизу

Давайте немного расширим наше представление о мусоре и введём для него дополнительное свойство — массу «типичного представителя», то есть массу одной пластиковой бутылки или листка бумаги, например.

abstract class Garbage{
   public abstract double getWeight();
}

class Paper extends Garbage{
   @Override
   public double getWeight() {
       return 0.01;
   }
}

class Plastic extends Garbage{
   @Override
   public double getWeight() {
       return  0.3;
   }
}

Теперь попробуем использовать эту массу в методе уже знакомого класса Box:

class Box<T> {

   private T item;

   public double getItemWeight() {
       // не скомпилируется
       return item == null ? 0 : item.getWeight();
   }
//... остальные методы
}

И получим ошибку при компиляции: мы не рассказали компилятору, что T — это какой-то вид мусора. Исправим это с помощью так называемого upper bounding — ограничения сверху:

class Box<T extends Garbage> {
// методы класса
}

Теперь метод getItemWeight успешно скомпилируется.

Здесь T extends Garbage означает, что в качестве T можно подставить Garbage или любой класс-наследник Garbage. Из уже известных нам классов это могут быть, например, Paper или Plastic. Так как и у Garbage, и у всех его наследников есть метод getWeight, его можно вызывать в новой версии дженерик-класса Box.

Для одного класса или интерфейса можно добавить сразу несколько ограничений. Вспомним про интерфейс для пункта приёма мусора и введём класс для метода переработки — HandleMethod. Тогда GarbageHandler можно переписать так:

class HandleMethod {
}

interface GarbageHandler<T extends Garbage, S extends HandleMethod> {
       void handle(T what, S how);
   }

Wildcards

До этого мы использовали для параметров типов буквенные имена, но в Java есть и специальный символ для обозначения неизвестного типа — «?». Его принято называть wildcard, дословно — «дикая карта».

Wildcard нельзя подставлять везде, где до этого мы писали буквенные обозначения. Не получится, например, объявить класс Box<?> или дженерик-метод, который принимает такой тип:

class Box<?>{ // не скомпилируется       
   ? variable;  // не скомпилируется
   public <?> void someMethod(? param){ // не скомпилируется
    //...   
   }
}

Wildcards удобно использовать для объявления переменных и параметров методов совместно с классами из Java Collection Framework — здесь собраны инструменты Java для работы с коллекциями. Если вы не очень хорошо знакомы с ними, освежите знания, прочитав эту статью.

В примере ниже мы можем подставить вместо «?» любой тип, в том числе Paper, поэтому строка успешно скомпилируется:

List<?> example1 = new ArrayList<Paper>();

Wildcards можно применять для ограничений типов:

List<? extends Garbage> example2 = new ArrayList<Paper>();

Это уже знакомое нам ограничение сверху, upper bounding, — вместо «?» допустим Garbage или любой его класс-наследник, то есть Paper подходит.

Но можно ограничить тип и снизу. Это называется lower bounding и выглядит так:

List<? super Garbage> example3 = new ArrayList<Garbage>();

Здесь <? super Garbage> означает, что вместо «?» можно подставить Garbage или любой класс-предок Garbage. Все ссылочные классы неявно наследуют класс Object, так что в правой части ещё может быть ArrayList<Object>.

Собираем понятия, связанные с дженериками

Мы не успели разобраться с более сложными вещами — например, с заменами аргументов типов в классах-наследниках, с переопределением дженерик-методов, не узнали об особенностях коллекций с wildcards.

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