Пример:
class Person
{
@OneToMany
List<Action> actionHistory;
@ManyToOne
Employer employer;
private StateEnum myCurrentState = StateEnum.INITIAL_STATE;
}
Представьте себе ситуацию, подобную этой, где две вещи верны:
Person.myCurrentState необходимо изменить в ответ на изменения в actionHistory, работодателе и т. Д. Существует ряд бизнес-правил, таких как «Если действие типа X отображается в потоке действий и текущее состояние равно Y, тогда установите новый статус до Z "
Человек должен иметь возможность блокировать и разрешать некоторые операции над дочерними элементами в зависимости от его текущего состояния. Например, при определенных условиях может оказаться невозможным обновить название должности у работодателя или невозможно добавить действия, соответствующие определенным критериям.
Первоначально я думал, что просто попытаюсь направить весь доступ к детям через процедуры в Person, которые содержат проверку / responselogic. В результате объект Person стал слишком большим и повсеместным из-за того, сколько операций детей ему необходимо было отслеживать. (Т.е. вместо просто getAEmployer (), setNewEmployer () и тому подобное, это также такие вещи, как updateJobTitleAtEmployer () и т. Д.)
Распространение логики на детей кажется таким же грязным. В этом случае работодатель (например) должен содержать тонны ссылок на своего родителя. Также деловые правила, связанные с этим материалом, разбросаны повсюду.
Есть ли какое-то чистое общее решение этой проблемы? Мне нужен какой-то общий способ, чтобы я мог иметь ветеринара родительского класса, а в некоторых случаях реагировать на определенные изменения состояния у многих его детей.
UPDATE:
Я думаю, что я неправильно использовал термины «родитель» и «ребенок» в этом вопросе. Я использую их так: у родителя "есть ребенок / родитель", состоящий из ребенка ". В примере Person будет родительским классом, а классы свойств будут дочерними.
Лучший пример:
class Employee
{
private Contract contract;
private List<Action> actions;
private EmployeeState currentState = EmployeeState.INITIAL;
}
Представьте себе, что в этом случае currentState может измениться, если что-то из контракта изменится (например, если скорость повысится). Также может быть так, что определенные вещи не могут быть установлены в Контракте, если Сотрудник находится в определенных штатах. В случаях, когда currentState изменяется, свойства Контракта являются лишь одним фактором в большем расчете (т. Е. Состояние может определяться правилами, например, «если Contract.hourlyRate> 30, а действия содержат Action с этими свойствами, а state is ...»).
Кроме того, в этом случае добавление действия может изменить состояние Employee или заблокироваться в зависимости от текущего состояния.
Вероятно, что-то не так с моей моделью, если я сталкиваюсь с этими проблемами?