Использование аннотации @Accessors Ломбока

1. Обзор

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

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

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

2. Стандартные аксессуары

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

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

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

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

@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()); 
}

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

3. Плавные аксессуары

Давайте начнем с опции fluent :

@Accessors(fluent = true)

То беглый опция дает нам средства доступа, которые не имеют получить или набор префикс.

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

@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. Цепные Аксессоры

Теперь давайте взглянем на опцию chain :

@Accessors(chain = true)

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

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

Давайте опираться на наши fluent аксессоры и изменим параметр 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());
}

Обратите внимание, как оператор new становится длиннее с помощью сеттеров , связанных вместе, удаляя некоторые шаблонные шаблоны.

Это, конечно, то, как Lombok @Builder использует chain ed fluent accessors.

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

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

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

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

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

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

@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 , а средства доступа для dbbalance пропускают начало bd .

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

Это гарантирует, что если у нас есть поле, которое не использует венгерскую нотацию, например state, , но начинается с одного из наших префиксов 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, и prefix опции аннотации Lombok @Accessors в различных комбинациях, чтобы увидеть, как это повлияло на сгенерированный код.

Чтобы узнать больше, обязательно ознакомьтесь с Lombok Accessors JavaDoc и Руководство по экспериментальным функциям .

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