Я бы не использовал наследование для представления состояния (активировано / деактивировано) ваших пользовательских объектов. Композиция (агрегация) здесь намного лучше.
Используя агрегацию, AbstractUser просто становится пользователем. Возможно, вы захотите смоделировать активацию с помощью класса, а не загрязнять класс пользователя атрибутами, связанными с активацией. Таким образом, вы получите красивую и чистую объектную модель.
На уровне базы данных вы все еще можете решить сохранить два объекта в одной таблице / записи, известной как Сопоставление компонентов . Или вы можете решить хранить пользователя и активацию в отдельных таблицах (или Отображение сущности ).
Hibernate поддерживает оба типа отображений, в основном это вопрос конфигурации.
Класс User будет содержать следующие атрибуты:
- GivenName
- фамилия
- Адрес электронной почты
- активация (ссылка на объект активации)
Класс активации будет содержать следующие атрибуты:
- код активации (строка)
- sentOn (когда было отправлено письмо)
- activOn (по умолчанию null, устанавливается на текущую дату / время, когда пользователь щелкает ссылку активации, сообщает системе, активировал ли пользователь свою учетную запись, когда не имеет значение null)
Вы можете использовать HQL-запрос, чтобы узнать, в какой компании есть хотя бы один активированный пользователь:
from Office o
left join fetch o.company
where
o.administrator.activatedOn != null
В этом запросе предполагается, что вы определили атрибут «администратор» в своем классе Office. «Администратор» - это ссылка на пользователя, который создал Office. В базе данных таблица «офисы» имеет внешний ключ к записи пользователя.
Моделируя отношения таким образом, вы можете сменить Администратора Офиса (например, он ушел или был уволен из Офиса / Компании). Все зависит от ваших вариантов использования ...
Я также добавил атрибут sentOn в класс Activation, используемый для очистки инактивированной учетной записи через некоторое время (отсутствовало в диаграмме UML).