Как моделировать неизменяемые объекты статическим фабричным методом

Question

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

Рассмотрим эту сущность (отредактировано по предложению Йенса Шаудера):

@Getter
@RequiredArgsConstructor(staticName = "of", access = AccessLevel.PACKAGE)
public final class Student {

    private final @Id @Wither
    long studentId;

    @NotNull
    @Size(min = 4, max = 20)
    private final String userId;

    @NotNull
    @Min(0)
    private final int matriculationNumber;

    @NotNull
    @Email
    private final String eMail;
}

Итак, эта сущностьдолжен быть неизменным и предлагает статический of метод создания.Также RequiredArgsConstructor создает закрытый конструктор , хотя он должен создавать пакет, видимый для всех полей, не имеющих значения NULL, для каждого определения.Короче говоря, я сделал, так сказать, AllArgsConstructor.

Этот документ здесь подробно описан https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#mapping.fundamentals. В разделе «Внутренние элементы создания объекта» изложены 4 аспекта для улучшенной обработки - «конструктор, который будетИспользуемые Spring Data не должны быть приватными"среди других, которые выполняются на мой взгляд.

Итак, мой вопрос: правильно ли выполнена эта изображенная сущность обоими способами в отношении оптимального картирования внутренних данных и данных пружины jdbc?

РЕДАКТИРОВАТЬ:

Тампохоже, это ошибка с плагином lombok в intellij, мешающая access = AccessLevel.PACKAGE делать правильные вещи.Смотрите здесь: https://github.com/mplushnikov/lombok-intellij-plugin/issues/584

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

Answer 1

Это зависит от вашего определения «оптимального отображения».

Это должно работать, так что это уже что-то.

Но оптимизация, описанная в документации, не может быть применена, потому что ваш конструкторчастный.Поэтому вы теряете прирост производительности на 10% по сравнению с тем, что, вероятно, не делает его «оптимальным».

Но прирост в 10% связан с созданием объекта.Речь идет не об обратном пути к базе данных, которая включает:

• извлечение данных из ваших сущностей
• построение (или поиск) SQL для использования
• отправка обоихв базу данных
• , выполняющую запрос в базе данных
• , возвращающий результат

Это очень вероятно, что выигрыш от этой оптимизации значительно ниже 10% ив большинстве случаев не о чем беспокоиться.

Конечно, вы никогда не узнаете, пока не сделаете свои собственные тесты с реальными данными.Для этого вам нужно создать конструктор all args, который имеет как минимум область действия пакета.