ООП дизайн для удаления объекта со многими зависимыми объектами

Question

Я хотел бы знать, как лучше спроектировать удаление объекта с помощью триггеров удаления многих зависимых объектов.

Вот пример.Есть класс работодателя.Когда работодатель удаляется, все его задания, счета-фактуры удаляются.Когда работа удаляется, выбор ее категории также удаляется.И так далее.Таким образом, вы можете видеть, что удаление Employer вызывает удаление еще многих объектов.Проблема в том, что мне нужно передать много аргументов, необходимых для удаления зависимых объектов, методу delete в классе Employer.

Вот упрощенный пример.Представьте себе класс Main.Когда основной объект удаляется, объекты Dep1, Dep2 также должны быть удалены.Когда Dep1 удаляется, Dep11 также должен быть удален.Если методы удаления выглядят так: Dep1.delete (arg1), Dep2.delete (arg2), Dep11.delete (arg3), то метод удаления в Main должен выглядеть следующим образом: Main.delete (arg1, arg2, arg3),Ты видишь?Чем больше объектов зависит от Main - тем больше аргументов потребуется для удаления.

Я также должен указать, что меня интересует удаление из базы данных, то есть удаление в смысле «бизнес-логики».Я даже не удаляю «удаленные» объекты в методе удаления.

Какие варианты я рассмотрел:

• группирование аргументов, необходимых для удаления, в отдельный объект.Я просто не вижу, как все эти аргументы можно сгруппировать.Они просто не принадлежат друг другу.Например, если необходимы Invoice_searcher и Job_searcher - зачем им объединяться в одном объекте?И что это может быть за объект?
• перемещение удаления зависимых объектов из метода delete в классе Employer.В этом случае явный отказ от вызова методов удаления для дочерних элементов приведет к несогласованности состояния системы.Я бы хотел этого избежать.

Answer 1

Если вы передаете параметры в функции удаления, вы делаете ошибку.

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

Я подчеркиваю объект , потому что звучит так, будто вы подходите к этому с точки зрения отношений.

Answer 2

В моей работе мне не нужно писать много кода для удаления, поэтому прислушайтесь к моему совету.Это может помочь посмотреть, как создаются эти объекты / записи, и обработать удаление таким же образом.Например, если логика создания выглядит следующим образом:

1. Создать работодателя
2. Создать счет
3. Связать счет с работодателем

чемвозможно, логика удаления должна выглядеть следующим образом:

1. Удалить связи счетов-фактур с работодателем
2. Удалить счета-фактуры
3. Удалить работодателя

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

Answer 3

Старайтесь использовать Композицию таким образом, чтобы после того, как вы сделаете ссылку на сотрудника меньше, автоматически станет меньше ссылки ...

Другой способ - воспользоваться вложенным классом, если самый верхний инкапсулирующий класс получит unreferenced other также автоматически получит unreferenced .. (но убедитесь, что вы не вытаскиваете ссылку на вложенный класс (скажем, ваш внутренний класс) в какой-то другой класс.)