3.2 KiB
aliases | tags | date | zero-link | parents | linked | article | |||
---|---|---|---|---|---|---|---|---|---|
|
|
https://struchkov.dev/blog/ru/do-not-use-lombok-data/ |
Многие разработчики в принципе против использования Lombok. В общем, это холиварная тема. Но вы используете Lombok в проекте, то не используйте хотя бы спорные и откровенно вредные аннотации.
Одна из таких – это @Data
. Во-первых, мало кто помнит, что она под собой скрывает.
@ToString
. Не помню, когда последний раз переопределялtoString()
. А если объект содержит чувствительную информацию?@EqualsAndHashCode
. Это самая вредная аннотация в @Data. ==Потому что она генерируетequals()
иhashCode()
по всем полям.== Обычно вы не хотите, чтобы генерация осуществлялась по всем полям. Например, для сущности достаточно идентификатора.@Getter
/@Setter
. Здесь ничего плохого.@RequiredArgsConstructor
. Тоже окей.
Основная проблема в @EqualsAndHashCode
. Можно, конечно, использовать @EqualsAndHashCode.Exclude
. Эта аннотация запрещает использовать поле при генерации, но вы хотите расставлять это над почти всеми полями в сущности? Потому что @EqualsAndHashCode.Include
просто не сработает, нельзя объявить только нужные поля, нужно будет именно исключать все ненужные.
Также избегайте всех аннотаций из пакета experemental
. Все аннотации из этого пакета могут работать не стабильно, и при этом могут быть удалены из следующих версий. Исключением из этого пакета является @FieldNameConstants, за пару лет с ней не было никаких проблем, а все имеющиеся альтернативы не очень.
С Lombok код выглядит чище, но, как и в случае с любым другим магическим инструментом, важно понимать, как именно он работает и когда его использовать. В противном случае производительность приложения может снизиться, либо оно вовсе может перестать работать корректно.