Цитата(Shklyar @ 19.7.2018, 23:32  ) | Цитата(Се ля ви @ 19.7.2018, 15:23 )
в твоём случае "странного" использования equals`а,
Не в моем. Вот посмотрел, и рад бы поругаться, да все тут ок. |
equals - это проверка на эквивалентность, т.е. с т.з. предметной области - эти объекты - полные аналоги друг друга. То, что туда не обязаны входить все поля, означает, что они не значимы. Я сегодня могу одеть синюю майку, а завтра красную - но это всё равно останусь я и equals меня в синей майке со мной в красной должен выдавать true. Так же и тут - не вхождение полей в проверку по equals`у означает лишь то, что эти поля не являются идентифицирующими и не важны с т.з. предметной области задачи, но ожидания у програмиста, когда он видит, что два объекта equals именно такие - что это по сути один и тот же объект, просто в силу особенностей алгоритма решаемой задачи оказавшийся скопированным в различные области памяти.
| Цитата(Shklyar @ 19.7.2018, 23:32 ) | | Почему в мапе пут возврашает E? |
Это просто удобно, это т.н. pipeline-стиль написания кода. В Java он известен давно по классам StringBuilder/Buffer, но действительно активно применяется, начиная с Java 8 в Stream`ах, CompletableFuture`ах, Optional`ах - тебе нужно что-то сделать с объектом, но перед этим необходимо положить его в мапу по какому-то ключу. Если бы этого поведения не было, то ты кладёшь объект в мапу одной операцией, и только второй делаешь с ним то, что нужно - в итоге у тебя две операции вместо одной со всем сопутствующим гемороем - блок придётся ставить, если это в лямбде, внутри цикла или if`а, в тернарный оператор не воткнёшь... Очень громоздкий код получается и увеличивается количество точек, где можно совершить ошибку.
| Цитата(Shklyar @ 19.7.2018, 23:32 ) | | Про Lombok интересен такой вопрос: какие проблемы ты встречал или видишь системными? Слышал мнение, что кто-то долго парился с тем, что натворил Lombok. Я особо не встречал, максимум цикличность, которая детектится с первого раза. |
Lombok - это не магия! Он простой, как топор и делает с твоим кодом совершенно очевидные, элементарные вещи по устранению boilerplate-кода (т.е. такого кода, за которым не стоит принятия решений, а он является тавтологией и его приходится писать просто из-за того, что язык этого требует). Уже достаточно давно был сформулирован принцип борьбы с таким кодом, который получил название "Convention over Configuration" ("Соглашения по конфикурации"), которому мы обязаны прогрессу в Computer Science последние лет 15, поскольку большинство новых разработок в Java-мире - Spring, Maven, Gradle, Lombok, Vavr, а так же языки и инструменты, проектировались в соответствии с этим принципом.
Главное правило использования Lombok`а - как только тебе кажется, что Lombok делает что-то непонятное для тебя - применяешь действие "delombok" и смотришь, во что Lombok превратил твой код, пока не поймёшь. Большую часть деломбока вообще берёт на себя плагин к идее (просто кликаешь правой кнопкой мыши на классе и выбираешь Refactor -> Delombok -> {имя интересующей аннотации или "All lombok annotations" для всех}), но если аннотации в этом списке нет, можно использовать мавеновский плагин, вот моя конфигурация:| Код | <!-- LOMBOK -->
<plugin>
<groupId>org.projectlombok</groupId>
<artifactId>lombok-maven-plugin</artifactId>
<version>1.18.0.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>delombok</goal>
</goals>
<configuration>
<addOutputDirectory>false</addOutputDirectory>
<sourceDirectory>src/main/java</sourceDirectory>
</configuration>
</execution>
<execution>
<id>test-delombok</id>
<phase>generate-test-sources</phase>
<goals>
<goal>testDelombok</goal>
</goals>
<configuration>
<addOutputDirectory>false</addOutputDirectory>
<sourceDirectory>src/test/java</sourceDirectory>
</configuration>
</execution>
</executions>
</plugin> |
Посмотри доклад Цикура, он там конечно далеко не про всё рассказывает, но для начала сойдёт - https://youtu.be/VGewqN_x0oQ
Что касается недостатков, они, опять же, сейчас (начиная с 10-й Java) теперь присущи и ей самой - это связано с т.н. "type inference" - когда ты вместо типа пишешь в простой Java var, а с lombok`ом - val. Дело в том, что с т.з. читабельности кода для человека это допустимо только в ситуации, когда из правой части выражения очевидна левая. Часто этим злоупотребляют и пишут val/var даже в тех случаях, когда при чтении кода непонятен выводимый из контекста тип переменной. Этого надо избегать. http://openjdk.java.net/projects/amber/LVTIstyle.html, но если подытоживать, то практика должна быть такой:
Используйте val/var только если верен хотя бы один пункт из списка:- в правой части выражения вызывается конструктор, например
| Код | val x = new MyClass(); |
- в правой части вызываается Builder, например
| Код | val x = MyClass.builder().x(1).y(2).build();
val y = MyClass.newInstance(); |
- в правой части вызывается метод, из названия которого очевиден (!) тип, например
| Код | val c = DriverManager.getConnection(url, props);
val s = c.createStatement(); |
- переменная в левой части называется так же, как тип, только с маленькой буквы, например
- переменная в левой части названа так, что предполагает (!) определённый тип, например
| Код | val dob = ...; // Date of birth, так что тип, очевидно, LocalDate или Date, а что именно - должно быть понятно из контекста
val name = ...; // Чем может быть имя, кроме строки?
val size = ...; // Тут либо int, либо long, а что именно - должно быть понятно из контекста |
При соблюдении этих правил проблем не возникает.
Лично я только благодаря Lombok`у и Vavr`у в принципе способен ещё писать на Java, от которой без них меня уже просто тошнит. Если бы ты изучил другие языки JVM, типа Groovy, Kotlin`а и тем более Scala`ы, у тебя - поверь - было бы то же самое.
И - да, в продакшене я и многие мои коллеги его использовал, использую и, конечно, буду использовать, пока на Java приходится писать. Работаю я старшим разработчиком в EPAM`е, если что - можешь на меня ссылаться. |
))