Поставщик решения для хранения данных для Java, который поддерживает заключительные поля

Я очень плохо знаком с Java, но я разрабатывал привычку использовать финал везде, где возможная неизменность объявления, которая я думаю, является хорошей вещью. (Рассмотрите f#),

Я считал, что JPA не поддерживает заключительные поля. Будьте в спящем режиме, TopLink? Я не уверен в них, но я предпочитаю JPA на данный момент.

Это даже возможно теоретически - скажем, посредством отражения - для изменения заключительных полей после создания? Мое предположение было бы... НЕТ :)

То, что было бы, конечно, возможно для решения для персистентности, должно поддерживать конструкторов с параметрами. По крайней мере, я не вижу оснований, которые сделали бы это невозможным. Отображение было бы немного хитро, я предполагаю. Это - альтернативное решение.

Предложения?

Править: Я не знаком с точным определением для неизменного, таким образом, я использовал его в этом сообщении интуитивно. Объявление Неизменности здесь означает объявлять, что поле не может быть изменено. Извините за недоразумение.

8
задан naeron84 16 March 2010 в 16:23
поделиться

4 ответа

Неизменяемость объекта (обратите внимание на разницу между неизменяемым объектом и объявлением поля final - объект неизменен ТОЛЬКО, если ВСЕ поля являются окончательными, то есть состояние объекта не может измениться после создания) - очень деликатная тема. Мне они нравятся, и hibernate поддерживает их через @Immutable.

Не знаю о его статусе в JPA 2, но отвечу на вопрос о последних полях: вы МОЖЕТЕ изменить их значения, используя отражение, но отражение сильно ограничено в среде Java EE.

Чтобы прояснить основную проблему: если ваши POJO неизменяемы, то как постоянное решение воссоздает эти объекты? Допустим, у вас есть два последних поля типа int и конструктор для их инициализации. Уровень сохраняемости не может иметь никакой информации об их порядке или их именах (поскольку имена полей и параметров стираются во время компиляции).

Koshuke опубликовал блог об этом (в отношении JAXB, поддерживающего неизменяемые bean-компоненты), но не может найти его прямо сейчас.

6
ответ дан 5 December 2019 в 18:58
поделиться

Честно говоря, это странная идея.

Сделав поля final , вы сообщаете компилятору, что они никогда не изменятся после создания объекта. Как следствие, это разумное предположение - не настаивать на них, поскольку они никогда не изменятся. Что ж, написав это, я предполагаю, что у вас есть культура Java, но вопрос, который вы задаете, говорит об обратном.

В Java постоянные объекты «всегда» считаются POJO (другими словами, Java Beans). Java Bean должен иметь (чтобы считаться таковым) пустой конструктор, который позволит фреймворкам устойчивости и т. Д. Создавать его с помощью своего пустого конструктора, косвенно вызывая его через Class.newInstance () /.

Есть поля, в которых используются непустые конструкторы (например, контейнеры IoC - Guice, Spring и Tapestry IoC), но это выходит за рамки Java Beans, которые следует рассматривать как объекты данных.

-1
ответ дан 5 December 2019 в 18:58
поделиться

Конечные поля не могут быть изменены после создания по дизайну. Поступать иначе - очень плохая идея, потому что кто-то может полагаться на стандартное поведение.

В общем, фреймворки персистентности имеют дело с иерархиями «нормальных» объектов. У вас есть объекты, которые можно только создавать и удалять, но не изменять. Это очень странно, потому что, когда вы создаете объект, вы создаете для него какой-то идентификатор. Через этот идентификатор вы подключаете сущность к другим. Когда вы удаляете старую сущность и создаете другую, вы (как правило) получаете сущность с другим идентификатором. Итак, все соединения (внешние ключи) разорваны. Это целевое поведение?

0
ответ дан 5 December 2019 в 18:58
поделиться

Возможно, это не совсем то, к чему вы стремитесь, но принцип неизменности может быть легко поддержан неокончательными частными полями, имеющими только геттер. Компилятор фактически распознает это и генерирует код, который в значительной степени идентичен тому, что вы получили бы с полями, объявленными как final.

Это потребует от вас добросовестности и не изменять поля внутри содержащего класса (тогда как final будет обеспечивать это), но я думаю, что это не большая цена за гибкость, которую вы получаете. .

3
ответ дан 5 December 2019 в 18:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: