Как правильно моделировать эту полиморфную ассоциацию?

Question

Даны следующие сущности:

Контейнер
Пользователь
Клиент
Учреждение

Сущность Контейнер имеет связь с одной или несколькими сторонами через свойство AssignedToParties.

Container.AssignedToParties может содержать сочетание пользователей, клиентов и учреждений.

Какова модель рекомендованного домена для этого отношения.

Я рассмотрел следующие варианты:

1) Создайте отдельные свойства для каждого типа:

Container.AssignedToUsers
Container.AssignedToClients
Container.AssignedToInstitutions

Это выглядит довольно не элегантно, но не требует бизнес-логики для проверки типов или выполнения какого-либо сокращения.

2) Создать общий базовый класс "Сторона" для пользователя / клиента / учреждения

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

Это решение, как и # 3, потребует, чтобы система проверяла типы во время выполнения для принятия решений и затем передавала их либо пользователю / клиенту / учреждению для их обработки.

3) Создать интерфейс маркера IContainer. Назначить, что пользователь / клиент / учреждение реализует

Это, по крайней мере, обеспечит некоторую безопасность типов, но потребует проверки типов и снижения производительности.

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

Любой совет приветствуется.

Answer 1

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

Вместо этого, я бы либо попросил наблюдателя реализовать какой-либо метод (или свойство коллекции), чтобы начать наблюдать за контейнером (и в этом случае, сделав их IContainerWatcher или тому подобное, имело бы смысл), либо иначенаблюдение за функциональностью, полностью загруженной в службу, предназначенную для поддержки ассоциаций, как это делает механизм публикации / подписки.Концептуально это аналогично таблице соединений «многие ко многим» в схеме базы данных.