У меня есть ученик, который занимается бэкенд-разработкой Java в небольшой интернет-компании. Недавно в их компании появился новый технический директор. Он определяет множество спецификаций разработки, спецификаций журналов и даже требует, чтобы все использовали определенную IDE единообразно.
Но я и мой ученик жаловались не на это, а на то, что он действительно жаловался мне, так это то, что он не мог понять, что этот новый технический директор фактически запретил всем разработкам в компании использовать Lombok. Но нет четкой и убедительной причины.
Поэтому он подошел, чтобы поболтать со мной, и спросил, разумна ли моя просьба. Что касается этого вопроса, я думаю, что отправная точка технического директора хороша, но подход немного экстремальный.
Причина, по которой я говорю, что это хорошая отправная точка, заключается в том, что использование Lombok действительно приносит много проблем, и лично я не использую его активно на работе.
Причина, по которой я не использую его активно, заключается в том, что код некоторых коллег все еще используется, поэтому я также вынужден установить плагин Lombok.
Теперь, когда эта тема обсуждена, я кратко поделюсь некоторыми своими взглядами.
Каковы преимущества Ломбока?
Lombok — это очень полезный инструмент Java, который может помочь разработчикам избавиться от многословного кода Java, особенно для простых объектов Java (POJO). Это делается с помощью аннотаций.
Если вы знаете больше о Ломбоке, вы можете сначала пропустить этот абзац и посмотреть на него напрямую.Если вы не знакомы с ним, вы можете кратко понять его.
Чтобы использовать Lombok в своем проекте, вам нужно выполнить три шага:
1. Установите плагин Lombok в IDE
В настоящее время Lombok поддерживает множество IDE, включая основные Eclips, Intelji IDEA, Myeclipse и т. д.
Способ установки в IDEA следующий:
2. Импорт связанных зависимостей
Lombok поддерживает использование нескольких инструментов сборки для импорта зависимостей.В настоящее время он в основном поддерживает maven, gardle и ant.
Если вы используете maven для импорта следующим образом:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
</dependency>
В-третьих, использование аннотаций в коде
Способ упрощения кода Ломбока в основном достигается за счет аннотаций, среди которых обычно используются @Data, @Getter/@Setter, @Builder, @NonNull и т. д.
Если вы используете аннотацию @Data, вы можете просто определить Java Bean:
import lombok.Data;
@Data
public class Menu {
private String shopId;
private String skuMenuId;
private String skuName;
}
Использование аннотации @Data для класса эквивалентно одновременному использованию аннотаций @ToString, @EqualsAndHashCode, @Getter, @Setter и @RequiredArgsConstrutor, что очень полезно для классов POJO.
То есть автоматически помогает определить toString, Getter, Setter и другие методы в классе Menu в примере.
В приведенном выше примере вы можете обнаружить, что мы используем аннотацию @Data, чтобы значительно сократить объем кода и сделать его очень кратким. Это также основная причина, по которой многие разработчики стремятся использовать Lombok.
Кроме того, разные люди имеют разные мнения об использовании Ломбока, потому что многие люди использовали Ломбок и знакомы с его преимуществами, поэтому давайте сосредоточимся на проблемах, вызванных использованием Ломбока.
Что плохого в Ломбоке?
Товарищ по команде Strong X
Потому что использование Lombok требует от разработчиков установки соответствующих плагинов в IDE.
Если подключаемый модуль не установлен, использование IDE для открытия проекта на основе Lombok приведет к ошибкам, таким как метод не найден. Приводит к сбою компиляции проекта.
То есть, если один человек в команде проекта использует Lombok, то остальные тоже должны установить плагин IDE. В противном случае невозможно совместное развитие.
Что еще более важно, если Lombok используется в определяемом нами пакете jar, то все приложения, которые зависят от этого пакета jar, должны устанавливать подключаемые модули, что очень навязчиво.
Читабельность кода, низкая отлаживаемость
Использование Lombok в коде действительно может помочь сократить объем кода, потому что Lombok поможет автоматически сгенерировать большой объем кода.
Однако эти коды генерируются только на этапе компиляции, поэтому в процессе разработки многие коды фактически отсутствуют.
Широкое использование Lombok в коде приведет к значительному ухудшению читабельности кода, а также принесет определенные проблемы при отладке кода.
Например, если мы хотим знать, на какие классы ссылаются методы получения свойства в классе, это не так просто.
есть яма
Поскольку Lombok очень упрощает разработку кода, некоторые разработчики чрезмерно зависят от него.
В процессе использования Lombok, если вы не понимаете основных принципов различных аннотаций, легко получить неожиданные результаты.
Для простого примера мы знаем, что когда мы используем @Data для определения класса, он автоматически генерирует для нас метод equals().
Однако, если вы используете только @Data вместо @EqualsAndHashCode(callSuper=true), по умолчанию будет использоваться @EqualsAndHashCode(callSuper=false).В настоящее время сгенерированный метод equals() будет сравнивать только свойства подкласса и будет не рассматривать.Свойства унаследованы от родительского класса, независимо от того, открыты ли права доступа к свойствам родительского класса.
Это может привести к неожиданным результатам.
Влияет на обновление
Поскольку Lombok очень навязчив к коду, это может привести к большой проблеме, то есть повлияет на наше обновление JDK.
Согласно текущей частоте обновления JDK, новая версия будет запускаться каждые шесть месяцев, но, поскольку Lombok является сторонним инструментом и поддерживается командой разработчиков открытого исходного кода, скорость его итерации не может быть гарантирована.
Таким образом, если нам нужно перейти на новую версию JDK, это повлияет на то, что функции в нем не поддерживаются в Lombok.
Другая возможная проблема заключается в том, что собственные улучшения Ломбока также будут ограничены.
Поскольку приложение может зависеть от нескольких пакетов jar, а каждый пакет jar может зависеть от разных версий Lombok, что приводит к необходимости арбитража версии в приложении, а мы знаем, что арбитраж версии пакета jar не так прост, и существует высокая вероятность проблем.
разорвать инкапсуляцию
Я думаю, что есть способы избежать вышеперечисленных проблем. Но есть еще одна важная причина, по которой некоторые люди отказываются от использования Lombok, а именно то, что он нарушит инкапсуляцию.
Как мы все знаем, три основные характеристики Java включают инкапсуляцию, наследование и полиморфизм.
Если мы используем Lombok прямо в коде, он автоматически сгенерирует для нас геттер, сеттер и другие методы, а это значит, что все параметры в классе автоматически предоставляют методы установки и чтения.
В качестве простого примера определим класс корзины покупок:
@Data
public class ShoppingCart {
//商品数目
private int itemsCount;
//总价格
private double totalPrice;
//商品明细
private List items = new ArrayList<>();
}
//例子来源于《极客时间-设计模式之美》
Мы знаем, что количество товаров в корзине, сведения о товарах и общая цена на самом деле связаны раньше, и если их нужно изменить, они должны быть изменены вместе.
Однако мы используем аннотацию Lombok @Data для свойств itemsCount и totalPrice. Хотя мы определяем их как закрытые типы, мы предоставляем общедоступные методы получения и установки.
Внешний может свободно изменять значения этих двух свойств с помощью методов установки. Мы можем вызвать метод установки по желанию, чтобы сбросить значения свойств itemsCount и totalPrice, что также приведет к их несоответствию со значениями свойства items.
Определение объектно-ориентированной инкапсуляции таково: благодаря управлению доступом внутренние данные скрыты, а внешние могут получать доступ и изменять внутренние данные только через ограниченный интерфейс, предоставляемый классом. Следовательно, раскрытие методов установки, которые не должны быть раскрыты, является явным нарушением характеристик объектно-ориентированной инкапсуляции.
Хорошей практикой является не предоставлять геттер/сеттер, а предоставлять только общедоступный метод addItem и изменять три свойства itemsCount, totalPrice и items одновременно.
Суммировать
В этой статье описаны преимущества и недостатки широко используемого инструмента разработки Java Lombok.
Преимущество заключается в том, что использование аннотаций может помочь автоматически генерировать код, что значительно сокращает объем кода и делает его очень кратким.
Однако это не означает, что проблем с использованием Lombok нет.В процессе использования Lombok также могут возникнуть такие проблемы, как недружественность к товарищам по команде, недружественность к коду, недружественность к отладке и недружественность к обновлениям.
Кроме того, использование Lombok также приводит к проблемам, нарушающим инкапсуляцию.
Хотя в использовании Lombok есть много удобств, это также приносит некоторые проблемы.
Но, в конце концов, не рекомендуется использовать его в повседневной разработке.Я вообще придерживаюсь нейтрального отношения.Я не рекомендую вам слишком полагаться на него, и не требую от вас использовать его полностью.
Пока вы можете рассмотреть проблемы, которые он привносит в код, думая о его преимуществах, прежде чем оценивать, следует ли вводить Lombok в код, цель этой статьи достигнута!
Использованная литература:
time.geekgang.org/column/arity…