Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Какое-то странноватое и неинтуитивное определение алиаса получилось, через присваивание и будто бы создание ещё одной ссылки, уже с алиасом в качестве генерик-параметра. А дальше другой вариант — уже что-то похожее на объявление поля в классе. Или я что-то не так понял?
А, кстати, какой ближайший существующий аналог в других языках Вас натолкнул на подобную идею?
А, кстати, какой ближайший существующий аналог в других языках Вас натолкнул на подобную идею?
Предполагается, что алиасы никак не будут отражены в байт-кодеНу, как бы это и так понятно, если уж сами генерики никак не отражены в байт-коде…
На мой взгляд полезность фичи не оправдывает проблем с ее введением — generic-кода обычно мало. В частности, в JDK я думаю не найдется ни одного места, где ее можно применить.
generic-кода в продуманной системе может быть и довольно много. Зависит от того, насколько развернутая применяется бизнес-модель.
Простите мне мой скептицизм, но пахнет энтерпрайзом в плохом смысле этого слова :)
Я могу представить класс с двумя, ну от силы тремя generic-параметрами. В вашем примере совершенно неясно, почему необходим параметр X для метода method и при этом нет никакой связи между X и T, несмотря на то, что реализация предполагает, что связь все-таки имеет место (вызывается processElement, определенный для параметра T). Может быть, пример выбран не очень удачный?
В целом дженерики делают код несколько громоздким, но в большинстве случаев этого можно избежать, если разбивать функциональность на небольшие классы. Тогда вместо вместо сложных многоуровневых объявлений можно обойтись просто <T> и минимумом вайткардов. Затем в процессе комбинирования type inference сделает грязную работу за вас.
И не злоупотребляйте inner class'ами — это такое же зло, как и checked exceptions.
Я могу представить класс с двумя, ну от силы тремя generic-параметрами. В вашем примере совершенно неясно, почему необходим параметр X для метода method и при этом нет никакой связи между X и T, несмотря на то, что реализация предполагает, что связь все-таки имеет место (вызывается processElement, определенный для параметра T). Может быть, пример выбран не очень удачный?
В целом дженерики делают код несколько громоздким, но в большинстве случаев этого можно избежать, если разбивать функциональность на небольшие классы. Тогда вместо вместо сложных многоуровневых объявлений можно обойтись просто <T> и минимумом вайткардов. Затем в процессе комбинирования type inference сделает грязную работу за вас.
И не злоупотребляйте inner class'ами — это такое же зло, как и checked exceptions.
В скобках не зря написано — рассматривать только синтаксис.
Насчет громоздкого кода. Конструкции типа Enum<T extends Enum> встречаются не только в стандартной библиотеке ) А, например, граф, параметризуемый типами вершин и ребер — уже минимум два generic-типа. Детально расписывать устройство проекта не буду — это выходит за рамки данного топика. Но сложные generic все-таки иногда необходимы.
Насчет громоздкого кода. Конструкции типа Enum<T extends Enum> встречаются не только в стандартной библиотеке ) А, например, граф, параметризуемый типами вершин и ребер — уже минимум два generic-типа. Детально расписывать устройство проекта не буду — это выходит за рамки данного топика. Но сложные generic все-таки иногда необходимы.
Ты пробовал использовать какие-нибудь другие языки (в т.ч. на JVM) в схожей ситуации? Какой дает самый подходящий эффект?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширение Java: алиасы