Что такое вайлдкарды java

Использование generic wildcards для повышения удобства Java API

Доброго времени суток!

Исходный API

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

Интерфейс выглядит вполне адекватно и логично, пользователь без проблем может написать простой код для работы с хранилищем:

Однако, в чуть менее тривиальных случаях клиент вашего API столкнётся с неприятными ограничениями.

Возьмём последний метод, который читает значения, удовлетворяющие предикату. Что с ним может быть не так? Берём, да и пишем:

А ведь всё решается так просто! Нам нужно лишь слегка изменить сигнатуру метода:

Запись Predicate означает «предикат от V или любого супертипа V (вплоть до Object)». Данное изменение никак не ломает компиляцию существующего кода, зато устраняет абсолютно бессмысленные ограничения на параметр предиката. Клиент теперь может использовать свой предикат для Vehicle совершенно свободно:

Мы обобщим данный приём чуть ниже, и запомнить его будет совсем просто.

Запись Map буквально означает «мапка с ключами типа K или любого из подтипов K и со значениями типа V или любого из подтипов V».

Принцип PECS — Producer Extends Consumer Super

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

Этот принцип Joshua Bloch называет PECS (Producer Extends Consumer Super), а авторы книги Java Generics and Collections (Maurice Naftalin, Philip Wadler) — Get and Put Principle. Но давайте остановимся на PECS, запомнить проще. Этот принцип гласит:

Производитель и потребитель, кто это такие? Очень просто: если метод читает данные из аргумента, то этот аргумент — производитель, а если метод передаёт данные в аргумент, то аргумент является потребителем. Важно заметить, что определяя производителя или потребителя, мы рассматриваем только данные типа T.

В нашем примере Predicate — это потребитель (метод getAll(Predicate ) передаёт в этот аргумент данные типа T), а Map — производитель (метод putAll(Map ) читает данные типа T — в данном случае под T подразумевается K и V — из этого аргумента).

В случае, если аргумент является и потребителем, и производителем одновременно — например, если метод одновременно и читает из коллекции, и пишет в неё (плохой стиль, но всякое бывает) — тогда его нужно оставить как есть.

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

Вооружившись PECS-принципом, мы можем теперь пройтись по всем методам нашего MyObjectStore интерфейса и сделать улучшения там, где это требуется. Методы put(K, V) и get(K) улучшений не требуют (т.к. они не имеют аргументов с параметризованным типом); методы putAll(Map ) и getAll(Predicate ) мы уже и так улучшили, дальше некуда; а вот метод getAll(Collection ) имеет аргумент-производитель с параметризованным типом, который мы можем расширить. Вместо

и радуемся новому, более удобному API! (Заметьте, возвращаемое значение мы не трогаем!)

Другие примеры потребителя и производителя

Производителями могут быть не только коллекции. Самый очевидный пример производителя — это фабрика:

Хорошим примером аргумента, являющегося и производителем, и потребителем, будет аргумент вот такого типа:

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

Заключение

В этой статье мы познакомились с принципом PECS (Producer Extends Consumer Super) и научились его применять при разработке API на Java. Как показывает практика, даже в самых продвинутых программистских конторах об этом принципе некоторые разработчики не знают, и в результате проектируют не совсем удобное API. Но, к счастью, исправляются подобные ошибки очень легко, а запомнив мнемонику PECS однажды, вы уже просто не сможете не пользоваться ей в дальнейшем.

Источник

Автор: Брайен Гетц (brian.goetz@sun.com)
главный инженер, Sun Microsystems
Перевод: М. Орельская
Источник: http://www.ibm.com/developerworks

Опубликовано: 28.04.2009

Понимание wildcard capture

Одним из наиболее сложных аспектов generic-типов (обобщенных типов) в языке Java являются wildcards (подстановочные символы, в данном случае – «?»), и особенно – толкование и разбор запутанных сообщений об ошибках, происходящих при wildcard capture (подстановке вычисляемого компилятором типа вместо wildcard). В данной части «Теория и практика Java» (Java theory and practice) старейший Java-разработчик Брайен Гетц расшифровывает некоторые из наиболее загадочно выглядящих сообщений об ошибках, выдаваемых компилятором «javac», и предлагает решения и варианты обхода, которые помогут упростить использование generic-типов.

Дискуссия по поводу generic-типов не прекращается с тех самых пор, как они были добавлены в язык Java в JDK 5. Одни считают, что эти типы упрощают программирование за счет расширения системы типов и, следовательно, повышают способность компилятора проверять безопасность типов. Другие говорят, что введение generic-типов только увеличивает путаницу. Все мы при их использовании сталкивались с некоторыми моментами, заставляющими задуматься, но именно wildcards представляют собой самую сложную часть generic-типов.

Основы работы с wildcards

Generic-и являются средством выражения ограничений поведения классов или методов для исходно неизвестных типов. Например: «какой бы из типов ни использовался в этом методе для параметров x или y, эти параметры должны быть одинакового типа», «вы должны обеспечить параметр одинакового типа для обоих этих методов», или «возвращаемое значение foo() имеет тот же тип, что и параметр bar()».

Wildcards – специальные вопросительные знаки, отмечающие место, где должно оказаться название параметра типа. Они являются средством выражения ограничений в условиях неизвестности какого-нибудь типа. Первоначально эти знаки не являлись частью структуры generic-ов, унаследованной от проекта Generic Java (GJ), а были добавлены в процессе разработки дизайна за те более чем пять лет, что прошли между созданием JSR 14 и его последним выпуском.

Wildcards играют важную роль в системе типов. Они позволяют задать границы для семейства типов, определенных каким-нибудь generic-классом. Для generic-класса ArrayList тип ArrayList является супер-типом ArrayList с параметром любого типа T (так же, как обычный тип (raw type) ArrayList и корневой тип (root type) Object, но эти супертипы менее удобны при выполнении вывода типа).

У меня появился wildcard. Что теперь?

Листинг 1 содержит пример простого типа-контейнера Box, который поддерживает операции put и get. Box параметризован параметром T, описывающим тип содержимого контейнера. Например, Box может включать в себя только элементы типа String.

Листинг 1. Простой generic-тип Box

Одно из преимуществ wildcards состоит в том, что они дают возможность написать код, который может оперировать переменными generic-типов без знания их точных границ. Допустим, у вас есть переменная типа Box – такая, как параметр box в методе unbox() в листинге 2. Что же может делать unbox(), обрабатывая параметр box?

Листинг 2. Метод Unbox с wildcard-параметром

Что знает unbox() о типе возвращаемого значения у метода box.get()? Он знает, что это тип T для какого-то неизвестного T. Поэтому лучшее, что он может сделать – принять решение, согласно которому тип возвращаемого значения от get() является замещением неизвестного ранее типа T. В случае неограниченного wildcard этот тип представлен типом Object. Таким образом, выражение box.get() в листинге 2 возвращает значение типа Object.

Wildcard capture

Листинг 3 содержит код, который похож на работающий, но только похож. В данном случае берется экземпляр generic-типа Box, из него получается значение, и производится попытка установить это значение обратно в тот же Box.

Листинг 3. Взятое из box значение не может быть помещено обратно

Capture helpers

Несмотря на то, что компилятор отбрасывает здесь какую-то полезную информацию, существует способ заставить его данную информацию восстановить. Для этого нужно дать неизвестному wildcard-типу имя. В Листинге 4 показана реализация rebox(), включающая вспомогательный generic-метод, который это и делает:

Листинг 4. Использование хелпера

Вспомогательный метод reboxHelper() является generic-методом. Generic-методы вводят дополнительные параметры типов (помещаемые в угловые скобки перед типом возвращаемого значения), которые обычно используются для формулирования ограничений типов между параметрами и/или возвращаемым значением метода. Однако в случае reboxHelper() generic-метод не задействует параметр типа для определения ограничения типа, а позволяет компилятору – через вывод типа – дать имя параметру типа переменной box.

Можно было объявить и rebox() как generic-метод, как мы объявили reboxHelper(), но в разработке API это не считается хорошим стилем. Основной принцип разработки здесь – не давать никакого имени, если на это имя никогда не будет ссылок. В контексте generic-методов это означает, что если параметр типа показывается в сигнатуре метода только один раз, то он, скорее, должен быть wildcard, нежели именованным параметром типа. Вообще же, API с wildcards проще, чем API с generic-методами; разрастание имен типов в более сложном объявлении методов может сделать это объявление менее читаемым. Поскольку всегда существует возможность при необходимости восстановить имя с помощью private capture-хелпера, вышеописанный подход дает способ сохранять API чистыми, не удаляя при этом нужную информацию.

Вывод типа

Прием с capture-хелпером основан на выводе типов (type inference) и преобразовании при фиксации (capture conversion). Java-компилятор не выполняет вывода типов во многих местах, однако для параметров типа в generic-методах он это делает (другие языки гораздо больше полагаются на вывод типов, поэтому в будущем, возможно, разработчики расширят функции вывода типов в Java). При необходимости можно указать значение параметра типа, но только в том случае, если существует возможность именовать этот тип – а capture-типы нельзя именовать. Поэтому данный прием сработает лишь в том случае, если компилятор выводит тип сам. Именно преобразование позволяет компилятору создать заглушку названия типа для wildcard так, чтобы при выводе типов был выведен именно этот тип.

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

компилятор мог бы решить, что T имеет тип Integer, Number, Serializable или Object, но выбирает Integer, поскольку он является наиболее точно удовлетворяющим ограничениям.

Такое нарушение «принципа DRY» (Don’t Repeat Yourself – «Не повторяйся!») может раздражать, даже когда IDE готовы проделать за вас некоторую часть работы. Однако если реализация класса BoxImpl поддерживает generic-метод фабрики класса, как показано в Листинге 5 (это, в любом случае, хорошая идея), есть возможность сократить подобную избыточность в клиентском коде:

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

Если Box создается с использованием фабрики BoxImpl.make(), параметр типа достаточно указать всего один раз:

Помимо уменьшения количества нажатий на клавиши, продемонстрированная здесь техника использования фабричного метода имеет и другие преимущества по сравнению с использованием конструкторов: фабрикам классов можно давать более подробные имена, фабрики классов способны возвращать подтипы именованных типов возвращаемых значений, и они не обязательно должны создавать новый экземпляр объекта при каждом вызове, поскольку позволяют совместное использование неизменяемых экземпляров. (Чтобы узнать больше о преимуществах статических фабрик классов, обратитесь к статье «Effective Java, Item #1», см. раздел «Ресурсы»).

Заключение

Несомненно, wildcards могут вызывать затруднения. Одни из самых запутанных сообщений об ошибках, выдаваемых компилятором Java, связаны как раз с применением wildcards. Некоторые из наиболее сложных разделов спецификации языка Java также посвящены wildcards. Тем не менее, при правильном использовании wildcards чрезвычайно удобны. В данной статье описано два приема – использование capture-хелперов и generic-фабрик, преимущество которых заключается в использовании generic-методов и вывода типов. При надлежащем применении они помогают устранить значительную часть сложностей.

Ресурсы

Copyright © 1994-2016 ООО «К-Пресс»

Источник

Дженерики (Java, обучающая статья)

Предисловие

За основу данной статьи была взята информация из 6-ой главы книги «Oracle Certified Professional Java SE 7 Programmers Exams 1Z0-804 and 1Z0-805». Она была немного изменена (кое-где обрезана, а кое-где дополнена с помощью Google и Википедии). Здесь показаны далеко не все нюансы дженериков — для более подробной информации следует обратиться к официальной документации. Приятного прочтения.

Введение

Обобщённое программирование — это такой подход к описанию данных и алгоритмов, который позволяет их использовать с различными типами данных без изменения их описания. В Java, начиная с версии J2SE 5.0, добавлены средства обобщённого программирования, синтаксически основанные на C++. Ниже будут рассматриваться generics (дженерики) или > — подмножество обобщённого программирования.

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

Ниже пример реализации:

В вышеприведённом коде была допущена ошибка, из-за которой на консоли мы увидим следующее:

Теперь на время забудем об этом примере и попробуем реализовать тот же функционал с использованием дженериков (и повторим ту же ошибку):

Самое существенное отличие (для меня) в том, что при ошибке, аналогичной предыдущей, проблемный код не скомпилируется:

Думаю, многие согласятся, что ошибка компиляции «лучше» ошибки времени выполнения, т.к. чисто теоретически скомпилированный код с ошибкой может попасть туда, куда ему лучше бы и не попадать. Это очевидное достоинство дженериков. Теперь подробнее рассмотрим конструкции, относящиеся к дженерикам в этом примере. Для того, чтобы код скомпилировался, достаточно заменить строку

Посмотрим на декларацию BoxPrinter:

После имени класса в угловых скобках » » указано имя типа «Т», которое может использоваться внутри класса. Фактически Т – это тип, который должен быть определён позже (при создании объекта класса).

Внутри класса первое использование T в объявлении поля:

Здесь объявляется переменная дженерик-типа (generic type), т.о. её тип будет указан позже, при создании объекта класса BoxPrinter.

В main()-методе происходит следующее объявление:

Здесь указывается, что Т имеет тип Integer. Грубо говоря, для объекта value1 все поля Т-типа его класса BoxPrinter становятся полями типа Integer (private Integer val;).
Ещё одно место, где используется T:

Как и в декларации val с типом Т, вы говорите, что аргумент для конструктора BoxPrinter имеет тип T. Позже в main()-методе, когда будет вызван конструктор в new, указывается, что Т имеет тип Integer:

Теперь, внутри конструктора BoxPrinter, arg и val должны быть одного типа, так как оба имеют тип T. Например следующее изменение конструктора:

приведёт к ошибке компиляции.

Последнее место использования Т в классе – метод getValue():

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

При создании дженерик-классов мы не ограничены одним лишь типом (Т) – их может быть несколько:

Нет ограничений и на количество переменных с использующих такой тип:

Алмазный синтаксис (Diamond syntax)

Вернёмся немного назад к примеру со строкой кода:

Если типы не будут совпадать:

То мы получим ошибку при компиляции:

Немного лениво каждый раз заполнять типы и при этом можно ошибиться. Чтобы упростить жизнь программистам в Java 7 был введён алмазный синтаксис (diamond syntax), в котором можно опустить параметры типа. Т.е. можно предоставить компилятору определение типов при создании объекта. Вид упрощённого объявления:

Следует обратить внимание, что возможны ошибки связанные с отсутствием «<>» при использовании алмазного синтаксиса

В случае с примером кода выше мы просто получим предупреждение от компилятора, Поскольку Pair является дженерик-типом и были забыты «<>» или явное задание параметров, компилятор рассматривает его в качестве простого типа (raw type) с Pair принимающим два параметра типа объекта. Хотя такое поведение не вызывает никаких проблем в данном сегменте кода, это может привести к ошибке. Здесь необходимо пояснение понятия простого типа.

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

Теперь посмотрим на вот этот:

По результатам выполнения оба фрагмента аналогичны, но у них разная идея. В первом случае мы имеем место с простым типом, во вторым – с дженериком. Теперь сломаем это дело – заменим в обоих случаях

Для простого типа получим ошибку времени выполнения (java.lang.ClassCastException), а для второго – ошибку компиляции. В общем, это очень похоже на 2 самых первых примера. Если в двух словах, то при использовании простых типов, вы теряете преимущество безопасности типов, предоставляемое дженериками.

Универсальные методы (Generic methods)

По аналогии с универсальными классами (дженерик-классами), можно создавать универсальные методы (дженерик-методы), то есть методы, которые принимают общие типы параметров. Универсальные методы не надо путать с методами в дженерик-классе. Универсальные методы удобны, когда одна и та же функциональность должна применяться к различным типам. (Например, есть многочисленные общие методы в классе java.util.Collections.)

Рассмотрим реализацию такого метода:

Нам в первую очередь интересно это:

» » размещено после ключевых слов «public» и «static», а затем следуют тип возвращаемого значения, имя метода и его параметры. Такое объявление отлично от объявления универсальных классов, где универсальный параметр указывается после имени класса. Тело метода вполне обычное – в цикле все элементы списка устанавливаются в одно значение (val). Ну и в main()-методе происходит вызов нашего универсального метода:

Стоит обратить внимание на то, что здесь не задан явно тип параметра. Для IntList – это Integer и 100 тоже упаковывается в Integer. Компилятор ставит в соответствие типу Т – Integer.

А сейчас вопрос – какая (-ие) из нижеприведённых строк откомпилируется без проблем?

Ответ с пояснением:
Первый вариант неправильный, т.к. нельзя создавать объект интерфейса.
Во втором случае мы создаем объект типа ArrayList и ссылку на него базового для ArrayList класса. И там, и там дженерик-тип одинаковый – всё правильно.
В третьем и четвёртом случае будет иметь ошибка компиляции, т.к. дженерик-типы должны быть одинаковыми (связи наследования здесь никак не учитываются).

Условие одинаковости дженерик-типов может показаться не совсем логичным. В частности хотелось бы использовать конструкцию под номером 3. Почему же это не допускается?

Будем думать от обратного – допустим 3-ий вариант возможен. Рассмотрим такой код:

Wildcards (Маски)

Сейчас будут рассмотрены Wildcard Parameters (wildcards). Этот термин в разных источниках переводится по-разному: метасимвольные аргументы, подстановочные символы, групповые символы, шаблоны, маски и т.д. В данной статье я буду использовать «маску», просто потому, что в ней меньше букв…

Как было написано выше вот такая строка кода не скомпилируется:

Но есть возможность похожей реализации:

Под маской мы будем понимать вот эту штуку – » «.

А сейчас пример кода использующего маску и пригодного к компиляции:

Метод printList принимает список, для которого в сигнатуре использована маска:

И этот метод работает для списков с различными типами данных (в примере Integer и String).

Однако вот это не скомпилируется:

И ещё один маленький пример:

Тут не возникнет проблем компиляции. Однако нехорошо, что переменная numList хранит список со строками. Допустим нам нужно так объявить эту переменную, чтобы она хранила только списки чисел. Решение есть:

Данный код не скомпилируется, а всё из-за того, что с помощью маски мы задали ограничение. Переменная numList может хранить ссылку только на список, содержащий элементы унаследованные от Number, а всё из-за объявления: List numList. Тут мы видим, как маске задаётся ограничение – теперь numList предназначен для списка с ограниченным количеством типов. Double как и Integer наследуется от Number, поэтому код приведённый ниже скомпилируется.

То, что было описано выше называется ограниченными масками (Bounded wildcards). Применение таких конструкций может быть весьма красивым и полезным. Допустим нам необходимо посчитать сумму чисел различного типа, которые хранятся в одном списке:

Double-тип был использован для переменной result т.к. он без проблем взаимодействует с другими числовыми типами (т.е. не будет проблем с приведением типов).

На этом все. Надеюсь, данная статья была полезной.

Если Вам понравилась статья, проголосуйте за нее

Голосов: 175 Голосовать

Источник

Подробно о PECS

Всем привет. Сегодня я хочу поговорить о принципе PECS. Понимаю, что сейчас гуру программирования и многоопытные сеньоры в очередной раз впечатали ладонь в лицо, ибо «Java Generics появились в JDK 1.5, которая вышла 30 сентября 2004 года…». Но если есть те, для кого принцип PECS остаётся туманным и непонятным, а упорное гугленье только сгущает «туман», добро пожаловать под кат, будем вместе разбираться до полного духовного просветления. Хочу сразу предупредить, что в данной заметке не рассматривается, что такое дженерики и что такое wildcard. Если вы не знакомы с данными понятиями, то перед чтением необходимо с ними разобраться.

На первый взгляд кажется, что принцип PECS достаточно прост. Все, кто встречался с ним, знают, что это акроним, означающий «Producer Extends Consumer Super». Как объясняется в многочисленных статьях, если у нас есть некая коллекция, типизированная wildcard с верхней границей (extends) – то это, «продюсер». «Он только «продюсирует», предоставляет элемент из контейнера, а сам ничего не принимает». Если же у нас коллекция, типизированная wildcard по нижней границе (super) – то это, «потребитель», который «только принимает, а предоставить ничего не может».

Ну, вот собственно говоря и всё. Теперь мы овладели «тёмной магией» PECS и можем смело отправляться на собеседование в Гугл, чтобы сразить интервьюеров своей премудростью и многоопытностью. Остаётся одна небольшая формальность, запустить любимую IDE и для галочки убедиться, что всё так и есть: контейнеры, ограниченные по верхней границе, могут только предоставлять объекты, а контейнеры, ограниченные по нижней границе, являются только потребителями.

Для наглядности представим, что у нас есть иерархия классов, начинающаяся с Class0, который является предком для Class1, который в свою очередь является предком для Class2, и т.д. И есть некий метод, который принимает в качестве аргумента коллекцию, типизированную wildcard с верхней границей.

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

Досрочный ответ очевиден: объекты, содержащиеся в list, являются потомками Class3, следовательно, из list можно получить объекты Class4, Class5, Class6 и т.д. Если вы ответили именно так, то у меня для вас плохая новость – «очко уходит телезрителям»! Следующий кусок кода не скомпилируется:

Зато вот такой код будет корректным:

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

Но почему это так? Разве здесь нет противоречия? Лист содержит объекты-потомки для некоего класса, а получить из него мы можем только объекты, имеющие тип класса-предка. На самом деле, для компилятора здесь всё однозначно. Во время компиляции кода неизвестно, объекты какого именно класса будут содержаться в листе. Допустим, это будут объекты Class3. Тогда в этой строке

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

С этим разобрались. Но почему мы не можем ничего положить в данный лист? Какая религия запрещает нам это делать?

И тут мы плавно переходим ко второй части принципа PECS – «consumer super» («wildcard с super — это consumer, он только принимает, а предоставить ничего не может»).

Это то же самое, что написать:

И тут встаёт последний вопрос, который бы хотелось рассмотреть в рамках изучения PECS: почему из коллекции, типизированной wildecard с нижней границей, можно получить только объект класса Object?

Если вы внимательно прочитали всё, что написано выше, то уже, наверное, догадываетесь о том, каким будет ответ. Потому что конкретный тип объекта, типизированного wildcard будет известен только в момент выполнения программы, а коллекция, состоящая из объектов-потомков, не может содержать объекты-предки.

Если бы компилятор счёл данный код «легальным» (ведь Class2 является суперклассом для Class3)

то могла бы получится следующая ситуация: во время выполнения программы в метод будет передан List или вообще List (оба они соответствуют маске ) а объект-потомок (Class2 obj) будет ссылаться на предка ( list.get(0) ). Единственный способ этого избежать – получать из такого листа объект, имеющий тип, общий для всех других объектов в Java, то есть объект класса Object.

Вот и всё, что хотелось бы рассказать о принципе PECS. Надеюсь, моё объяснение вышло понятным и поможет страждущим истины разобраться в данном вопросе.

Источник