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

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 .