Перейти к основному содержимому

Использование аннотации Lombok @Accessors

· 5 мин. чтения

1. Обзор

Довольно типично иметь методы get и set в наших предметных объектах, но есть и другие способы, которые мы можем найти более выразительными.

В этом руководстве мы узнаем об аннотации @Accessors Project Lombok и ее поддержке плавных, связанных и настраиваемых методов доступа .

Однако, прежде чем продолжить, нашей IDE потребуется установленный Lombok .

2. Стандартные средства доступа

Прежде чем мы рассмотрим аннотацию @Accessors , давайте посмотрим, как Lombok по умолчанию обрабатывает аннотации @Getter и @Setter .

Во-первых, давайте создадим наш класс:

@Getter
@Setter
public class StandardAccount {
private String name;
private BigDecimal balance;
}

А теперь давайте создадим тестовый пример. В нашем тесте мы видим, что Lombok добавил типичные методы получения и установки:

@Test
public void givenStandardAccount_thenUseStandardAccessors() {
StandardAccount account = new StandardAccount();
account.setName("Basic Accessors");
account.setBalance(BigDecimal.TEN);

assertEquals("Basic Accessors", account.getName());
assertEquals(BigDecimal.TEN, account.getBalance());
}

Мы увидим, как изменится этот тестовый пример, когда посмотрим на параметры @Accessor .

3. Свободные средства доступа

Начнем с беглого варианта:

@Accessors(fluent = true)

Вариант Fluent дает нам методы доступа, у которых нет префикса get или set .

Через мгновение мы рассмотрим параметр цепочки , но, поскольку он включен по умолчанию, давайте пока отключим его явно:

@Accessors(fluent = true, chain = false)
@Getter
@Setter
public class FluentAccount {
private String name;
private BigDecimal balance;
}

Теперь наш тест по-прежнему ведет себя так же, но мы изменили способ доступа и изменения состояния:

@Test
public void givenFluentAccount_thenUseFluentAccessors() {
FluentAccount account = new FluentAccount();
account.name("Fluent Account");
account.balance(BigDecimal.TEN);

assertEquals("Fluent Account", account.name());
assertEquals(BigDecimal.TEN, account.balance());
}

Обратите внимание, как исчезли префиксы get и set .

4. Цепочки доступа

Теперь давайте посмотрим на вариант цепочки :

@Accessors(chain = true)

Опция chain дает нам сеттеры, которые возвращают этот . Еще раз обратите внимание, что по умолчанию он равен true , но мы установим его явно для ясности.

Это означает, что мы можем связать несколько операций над множествами вместе в одном операторе.

Давайте возьмем наши плавные методы доступа и изменим опцию chain на true :

@Accessors(fluent = true, chain = true)
@Getter
@Setter
public class ChainedFluentAccount {
private String name;
private BigDecimal balance;
}

Мы получим тот же эффект, если опустим цепочку и просто укажем:

@Accessors(fluent = true)

А теперь давайте посмотрим, как это повлияет на наш тестовый пример:

@Test
public void givenChainedFluentAccount_thenUseChainedFluentAccessors() {
ChainedFluentAccount account = new ChainedFluentAccount()
.name("Fluent Account")
.balance(BigDecimal.TEN);

assertEquals("Fluent Account", account.name());
assertEquals(BigDecimal.TEN, account.balance());
}

Обратите внимание, как новый оператор становится длиннее, когда сеттеры связаны вместе, удаляя некоторые шаблоны.

Это, конечно, то, как @Builder от Lombok `` использует цепные методы доступа .

5. Префиксные методы доступа

И, наконец, время от времени наши поля могут иметь другое соглашение об именах, чем мы хотели бы представить через геттеры и сеттеры.

Давайте рассмотрим следующий класс, который использует венгерскую нотацию для своих полей:

public class PrefixedAccount { 
private String sName;
private BigDecimal bdBalance;
}

Если бы мы представили это с помощью @Getter и @Setter , мы бы получили такие методы, как getSName , которые не так читабельны.

Опция префикса позволяет нам указать Lombok, какие префиксы игнорировать:

@Accessors(prefix = {"s", "bd"})
@Getter
@Setter
public class PrefixedAccount {
private String sName;
private BigDecimal bdBalance;
}

Итак, давайте посмотрим, как это повлияет на наш тестовый пример:

@Test
public void givenPrefixedAccount_thenRemovePrefixFromAccessors() {
PrefixedAccount account = new PrefixedAccount();
account.setName("Prefixed Fields");
account.setBalance(BigDecimal.TEN);

assertEquals("Prefixed Fields", account.getName());
assertEquals(BigDecimal.TEN, account.getBalance());
}

Обратите внимание, что методы доступа для нашего поля sName ( setName, getName ) опускают начальный s , а методы доступа для bdBalance пропускают начальный bd .

Однако Lombok применяет префиксы только в том случае, если за префиксом следует что-то, кроме строчной буквы.

Это гарантирует, что если у нас есть поле, которое не использует венгерскую нотацию, например состояние, но начинается с одного из наших префиксов, s , мы не закончим с getTate()!

Наконец, предположим, что мы хотим использовать символы подчеркивания в нашей нотации, но также хотим, чтобы за ними шла строчная буква.

Добавим поле s_notes с префиксом s_:

@Accessors(prefix = "s_")
private String s_notes;

Следуя правилу строчных букв, мы получим такие методы, как getS_Notes() , поэтому Lombok также применяет префиксы, когда сам префикс заканчивается чем-то, что не является буквой .

6. Свойства конфигурации

Мы можем установить значение по умолчанию для всего проекта или каталога для нашей любимой комбинации настроек, добавив свойства конфигурации в файл lombok.config :

lombok.accessors.chain=true
lombok.accessors.fluent=true

Дополнительную информацию см. в Руководстве по настройке функций Lombok .

7. Заключение

В этой статье мы использовали параметры fluent, chain и префикс аннотации Lombok @Accessors в различных комбинациях, чтобы увидеть, как это повлияло на сгенерированный код.

Чтобы узнать больше, обязательно ознакомьтесь с Lombok Accessors JavaDoc and Experimental Feature Guide .

Как обычно, исходный код этой статьи доступен на GitHub .