Я люблю Яву. С каждой минутой создается множество удивительных вещей, и мне действительно нравится быть частью этого сообщества. Но, честно говоря, есть одна вещь, которую я ненавижу. Это архитектура JavaBeans ™ .
Не полностью, но основные требования иметь нулевой конструктор и доступ к свойству с помощью методов getter и setter. Все это глупые накладные расходы, которые трудно поддерживать и изменять. Но есть маленький помощник, который сделал мою жизнь проще. Это проект Ломбок . Вот очень краткий обзор использования Lombok с ManagedBeans.
Начиная
Grep ваш любимый IDE (Eclipse / NetBeans) и запустите ваш новый веб-проект Java EE 6 на основе Maven. Добавьте зависимость Lombok в ваш файл pom.xml:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>0.10.0</version>
<scope>compile</scope>
</dependency>
И вы сделали. Если вы не используете Maven, получите свою копию lombok.jar с веб-сайта проекта . Вот и все. Вы сделали.
Кодирование ManagedBean с помощью Lombok
Создайте новый класс с именем «Customer» и добавьте несколько полей String:
public class Customer {
private String name;
private String sure_name;
private String nickname;
}
Но что произойдет, если вы попытаетесь использовать это как @ApplicationScoped @ManagedBean? Наверняка ваша среда выполнения JSF будет жаловаться на отсутствующие свойства и конструкторы. Но вместо добавления всего этого стандартного кода вы просто добавляете @Data в качестве дополнительной аннотации к вашему классу, который должен выглядеть следующим образом:
@ManagedBean
@ApplicationScoped
@Data
public class Customer {
private String name;
private String surename;
private String nickname;
}
Теперь возьмите простой интерфейс JSF и добавьте в него немного: <h: inputText id = «name» value = «# {customer.name}» /> для каждого поля в вашем бине, и все готово. Все работает. И никто больше не жалуется на пропавшие свойства!
Что произошло?
Предлагаемая аннотация Lombok @Data просто говорит вашей IDE, чтобы она генерировала весь стандартный код для вас молча. И это делается во время компиляции, поэтому вам обычно не нужно беспокоиться о том, что lombok находится на вашем пути выполнения. Есть некоторые исключения из этого правила с другими функциями Lombok, но это верно для этого простого примера. @Data, в частности, представляет собой удобную сокращенную аннотацию, которая объединяет функции @ToString , @EqualsAndHashCode , @Getter / @Setterи @RequiredArgsConstructor вместе: Другими словами, @Data генерирует весь шаблон, который обычно ассоциируется с простыми POJO (обычными старыми объектами Java) и bean-компонентами: геттеры для всех полей, сеттеры для всех не финальных полей и соответствующие toString, равно и Реализации hashCode, которые включают в себя поля класса, и конструктор, который инициализирует все конечные поля, а также все не конечные поля без инициализатора, которые были отмечены @NonNull или @NotNull, чтобы гарантировать, что поле никогда не будет нулевым , Если вы посмотрите на сгенерированный источник, то увидите, что скомпилированный файл находится там и содержит все ваши известные шаблоны:
>javap Customer
Compiled from "Customer.java"
public class net.eisele.lombokdemo.Customer {
public java.lang.String process();
public net.eisele.lombok_jsf.Customer();
public java.lang.String getName();
public java.lang.String getSurename();
public java.lang.String getNickname();
public void setName(java.lang.String);
public void setSurename(java.lang.String);
public void setNickname(java.lang.String);
public boolean equals(java.lang.Object);
public boolean canEqual(java.lang.Object);
public int hashCode();
public java.lang.String toString();
}
Вот и все?
Не совсем ? Есть еще несколько возможностей, которые может предложить Lombok . например, простой @Log, который дает вам доступ к закрытому статическому конечному полю журнала java.util.logging.Logger, чтобы просто регистрировать происходящее. Вы также можете иметь @ Log4j, @CommonsLog или даже @ Slf4j в качестве альтернативы. Если вы ищете всю богиню, посмотрите на страницу обзора возможностей проекта .
Риски?
One could argue that having all those fancy stuff done by a compiler could lead to unexpected results and probably introduces errors nobody likes. Right. But even if you don’t like all those automated and transparent generation, you could simply Delombok your source files. This would simply replace all lombok annotations with the generated code and gives your access to a complete codebase. So it’s a calculable risk using Lombok and I must admit: I love it.
From http://blog.eisele.net/2011/08/tired-of-getters-and-setters-lombok.html