Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Планируется ли обзор DI решений (Guice, Dagger, HK2)?
Беда начинается, когда требуется в одном проекте использовать и Lombok и AspectJ, они не очень дружат.
А можете рассказать, что происходит? Я не сталкивался с такими проблемами, вроде AspectJ по идее работает уже с сгенеренными классами (или я ошибаюсь?), а сгенеренные классы Lombok не отличаются от обычных.
palesz.wordpress.com/2011/12/03/howto-maven-lombok-and-aspectj-together
1. javac compiles your .java files to .class files with lombok (generating methods, etc.)
2. aspectj regenerates your classes from the .java files without lombok
Но, к сожалению, предложенный по ссылке вариант у меня не сработал. И не только у меня, насколько можно понять из issue того же lombok — github.com/rzwitserloot/lombok/issues/995
1. javac compiles your .java files to .class files with lombok (generating methods, etc.)
2. aspectj regenerates your classes from the .java files without lombok
Но, к сожалению, предложенный по ссылке вариант у меня не сработал. И не только у меня, насколько можно понять из issue того же lombok — github.com/rzwitserloot/lombok/issues/995
Никогда не понимал людей кто юзает эту либу.
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
Для нового продукта можно выбрать лаконичные scala или koltin.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Нужно принимать язык таким как каким он есть.
Для нового продукта можно выбрать лаконичные scala или koltin.
Можно, но если вся команда привыкла писать на Java почему бы и нет. У scala многих пугает сложность, понятно, что можно писать как чуть лучшая Java, но если работать с чужим кодом можно ничего не понять. koltin пока не так распространен. Данная библиотека это компромис между новым языком и старым.
А в бородатый энтерпрайз вряд ли кто то станет это внедрять.
Кроме энтерпрайза есть просто старые проекты, которые по каким-то причинам использовали Java (скажем, микросервисы). С одной стороны переходит на новый язык сложно, с другой добавление библиотеки позволяет рефакторить старый код. Вообще, в Java энтерпрайз все больше переходит на Spring Boot и микросервисы, а это могут быть совсем не огромные проекты.
Нужно принимать язык таким как каким он есть.
Не согласен, так можно было вообще писать на Java 5 или Java 3. Язык вполне гибкая штука, в Java огромное количество открытых библиотек, которые тоже расширяют возможности. По такой логики их тоже не стоит использовать.
Не согласен, так можно было вообще писать на Java 5 или Java 3. Язык вполне гибкая штука, в Java огромное количество открытых библиотек, которые тоже расширяют возможности. По такой логики их тоже не стоит использовать.
Вы передергиваете :) Речь ведь о языке в целом, а не конкретно какой-то её версии.
Генерация кода для DI вынужденная мера, тут я согласен.
В остальном, не западло прописать getter/setter потому что это Java, тут так принято.
Хотите нормальную аргументацию?
Для нормальной работы этого чудо модуля нужно ставить расширение для IntelliJ IDEA
Все эти генерации могут усложнить/замедлить скорость сборки проекта
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Ненужно пытаться нагнать всевдо-читаемость такими плагинами.
Если что, есть много других языков где ненужно писать getter/setter :)
Если что, есть много других языков где ненужно писать getter/setter :)
Эм… Много? Что-то как-то в голову даже 5 не приходит.
Все эта магия вгонит в ступор первого же человека кто начнет разбираться в таком коде.
Спринговый @Compontent тоже вгонит, так что ж теперь, Спрингом не пользоваться?
Аннотация @Compontent в отличии от аннотаций Lombok не дописывает код вместо вас, вот в чем разница!
Для человека, который этого не знает и та и другая аннотация выглядят магически и требуют времени для постижения того, что это такое и как работает, так что с этой точки зрения разница не велика. При этом, замечу, квикдок по аннотации Data первым делом сообщает: "Generates getters for all fields", плюс дает ссылку на сайт ломбока, что сильно помогает делу.
Я не знаю как по другому еще донести до вас суть. Вы меня не хотите слышать, эта ветка зашла в тупик.
парсер, что ты делаешь, прекрати
Ну мне лично не нравится синтаксис котлина и скали, а джава с си подобным синтаксисом очень даже ничего. В принципе сгенерировать через alt insert в идее эти геттеры сеттеры тоже не сложно, но ломбок вообще шикарен.
Есть объект класса, нужно вернуть его часть в виде json — я создаю отдельную обертку, которая в конструктор принимает этот объект, и берет из него все нужное, после чего объект обертки прогоняется через jackson, и на выходе получаем json. Jackson, как известно, пользуется для конвертации либо публичными полями, либо геттерами, поэтому одна единственная аннотация Data над классом-оберткой быстро и не заметно экономит мне время. Еще одна аннотация @Slf4j позволяет мне работать с логгером даже не думая о нем. В общем не очень понимаю ваше не понимание, о каком «внедрении в бородатый энтерпрайз» вообще идет речь? Это же библиотека, а не фреймворк — если удобно, то используем, если не удобно, то не используем.
Немного необычный подход с оберткой над объектом для генерации json.
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
Обычно делаются статические методы в хелпер-классе, например EntityHelper.toJson(myEntity)
В вашем случае идет совершенно ненужное создание +1 объекта обертки к каждой операции конвертации объекта в Json
Не буду спорить что ваш подход выглядит короче, круче :)
Ваш подход не подойдет в случае если нет однозначного соответствия Класс<->json. То есть в одном случае нужен json состоящий из некоторых полей класса А, в другом — из всех полей, а в третьем случае вообще должен быть композицией из A + B + C. Плюс мне нравится иметь возможность на вопрос «почему фронту приходит ЭТО вместо ЭТОГО?» пойти и подправить одну конкретную обертку гарантированно не затронув ничего по соседству. Я такие обертки вообще частенько создаю, как inner классы прямо по месту преобразования результата.
Нужно конечно видеть код, что бы подсказать альтернативный путь для решения этой задачи без дополнительных объектов-оберток.
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
Возможно что ваш подход хорошо подходит именно в вашем случае. Тут я спорить не буду.
А в чем проблема дополнительных оберток, кстати говоря? Формально понятно, лишняя сущность, но практически она маленькая, локальная и вопросов не вызывает. Стоит ли с ней бороться?
В вашем случае, на сколько я понял, это обертка возвращается вашим контроллером, по сути ничего, кроме эстетического момента меня не смущает.
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
Если же вы проектируете api какой-либо библиотеки, которую будут использовать сторонние разработчики, то тут я бы воздержался от таких конструкций. Разработчик может вызывать такой код в различных циклах миллионы раз, зачем провоцировать GC на лишнюю работу за зря?
Не совсем так. У меня выделена отдельная сущность «экшен», который с одной стороны может вызываться на выполнение фронтэндом, путем отправления по вебсокету специального сообщения, а с другой стороны в него интегрирован доступ к ядерным сервисам, которые обеспечивают работу самого приложения, и знать не знают ни о какой фронтовой части. То есть реализуя экшен (java код) на получение, к примеру, данных о работнике, которые на ядерном уровне распределены по нескольким компонентам, мы делам примерно так:
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А насчет библиотеки это да, тут согласен.
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А насчет библиотеки это да, тут согласен.
Пользую ломбок давненько, в основном Getter/Setter/ToString/Equal…
По моему удобно и Entity сокращаются в размерах в разы.
Только следить за циклическими зависимостями в ManyToMany и прочих подобных штуках надо путем использования exclude ну и с Equal… осторожно, в остальном просто супер.
По моему удобно и Entity сокращаются в размерах в разы.
Только следить за циклическими зависимостями в ManyToMany и прочих подобных штуках надо путем использования exclude ну и с Equal… осторожно, в остальном просто супер.
Табличный формат совершенно не удобен, вы разве не видите?
Выглядит круто, только вот один вопрос очень интересует: если физически в коде например геттеров/сеттеров нет (добавятся аннотацией), а ты их будешь юзать, не будет ли IDE их подчеркивать все время как ошибку? Она то не знает что они добавятся во время компиляции… И вообще как с ними автокомплит будет работать?
Для этой зависимости можно установить scope как provided, т.к. область действия функциональности ограничивается временем компиляции, что бы не тащить в билд эту либу.
Года 2-3 использую ломбок только для Dto и Entity (для остального скорей не нужно). Крутая вещь. Одной аннотацией избавляешься от некоторой кучи проблем, например, достаточно просто изменить название поля или тип и ничего не надо больше делать (перегенерить сеттеры, хэшкод и пр.). Проблем ни разу не было, Dto'шки довольно краткие и красивые, на перфоманс не влияет.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
"Много кода" - ссылка не открвается. Проверил в Firefox и Chrome. Может проще было бы оставить просто код?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шпаргалки Java программиста 10: Lombok