Почему JPA требует, чтобы классы Entity были не окончательными, а поля не окончательными
Читал о JPA здесь. Два требования к классу Entity заключаются в том, что
- Класс не должен быть объявлен окончательным. Никакие методы или постоянные переменные экземпляра не должны быть объявлены как final.
- Класс должен иметь общедоступный или защищенный конструктор без аргументов.
- Постоянные переменные экземпляра должны быть объявлены как private, protected или package-private.
Было любопытно узнать, зачем нужны эти условия?
Ответы 2
- The class must not be declared final. No methods or persistent instance variables must be declared final.
Реализации JPA используют прокси-серверы перед вашими сущностями для управления, например: отложенной загрузкой. Поскольку окончательный класс не может быть расширен, нельзя создать прокси.
Некоторые реализации, такие как Hibernate, могут сохранять окончательные классы, но это может повлиять на производительность больше информации.
- The class must have a public or protected, no-argument constructor.
Эти и другие фреймворки для создания новых объектов используют ```Class.newInstance()``, поэтому конструктор без аргументов не нужен.
- Persistent instance variables must be declared private, protected, or package-private.
Будучи доступным только через методы доступа или бизнес-методы, допускается перехват в прокси.
Да, в этом случае я бы сказал, что это больше, чем просто обертки объектов. Например: Integer вместо int. Но да, в основном, если вы используете карту для сопоставления отношений, ключ должен быть базового типа, объекта или встраиваемого. Если вы считаете, что мой ответ в порядке, можете проверить: stackoverflow.com/help/someone-answers
Причины (по крайней мере некоторые из них):
- Поставщику JPA необходимо динамически создавать экземпляры объекта. Если бы класс содержал единственный конструктор, который принимает произвольные аргументы, провайдер JPA не мог бы определить значения для этих аргументов. Вот почему он должен иметь конструктор без аргументов.
- Реализации JPA имеют дело с сохраняющимися экземплярами ваших классов сущностей. поэтому класс, методы и переменные не могут быть окончательными.
- Поскольку вам не нужен прямой доступ к переменным извне, чтобы сохранить инкапсуляция - это причина ООП. Другая причина заключается в том, что многие структуры постоянства имеют метод получения/установки для определения "свойств" POJO.
Привет спасибо! Можете ли вы также сказать, что они имеют в виду, когда говорят «базовый тип языка программирования Java» в том же документе. Я думаю, что они могут иметь в виду примитивные типы данных, но не уверен.