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

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 строит приватный конструктор, хотя он должен создать пакет, видимый для всех окончательных / ненулевых полей в определении. Короче я сделал AllArgsConstructor так сказать.

Этот документ здесь https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/ подробно раздел о "внутренних объектах создания объекта" содержит 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, который имеет как минимум область действия пакета.