Интересно: это всё тобой написано (поэтому ты можешь менять как угодно), или это части какой-то сторонней библиотеки (поэтому ты не можешь менять их, однако можешь делать собственные надстройки)?
Уточнения предметной области. Объяснение твоё не замкнуто на само себя и потому не полно.
Есть документ с кучей электронных карт (участки, дороги, светлофоры, проч). Документ - это просто набор этих карт (слоев),
чтобы пользователь мог сгенерировать паспорт придомовой территории по клику на выбранный участок (территорию эту ж).
Затем по клику на участок объект класса Yard "собирает" инфу об участке по его ID.
Нигде нет определения, что такое "участок" или "территория". Известно лишь, что эта сущность имеет ID. Также сказано, что "участки, дороги, светофоры" - это карты, что, скорее всего, является некорректным утверждением. Например, может быть "карта светофоров" (одна сущность) и "светофор" (другая сущность) на (отношение между сущностями) "карте светофоров"
Имеется карта (может это отдельная сущность, здесь не упомянутая, или это документ?) из слоёв LayoutMap. Пользователь на неё тыкает в какую-то точку, и, допустим, карта возвращает ему набор объектов-областей (тех самых участков/территорий?) в этой точке из всех слоёв. Как на самом деле?
Если на самом деле так, по каким правилам между собой увязываются объекты-области в случае несовпадения координат? Например, пользователь указывает на улицу (как область одного слоя), а на этой улице по всей её площади разбросано множество светофоров. В случае выбора улицы светофоры тоже выбираются как привязанные к улице или нет? Или, например, на придомовой территории находится автостоянка или трансформаторная будка - они тоже должны выбраны вместе с территорией или нет?
собсно инфа о территории (сущность Yard).
Я правильно понимаю, что эта информация о территории - не географическая информация? Т.е. Yard и "участок" между собой не увязаны по каким-то идентификаторам, и являются атрибутами какой-то третьей сущности (LayoutPassport?), которая их в себе объединяет для описания придомовой территории.
Если это так, то непонятно отношение композиции между LayoutPassport (как предполагаемого мною паспорта придомовой территории) и LayoutMap (как предполагаемого мною слоя карты), причём так, что слой карты является частью паспорта придомовой территории. Насколько я понимаю, в таком случае один слой карты будет входить во множество паспортов придомовых территорий.
По логике предметной области между этими сущностями может быть либо ассоциативная связь, либо вместо LayoutMap внутри LayoutPassport должны находится "участки" на разных LayoutMap, относящиеся к данной придомовой территории (более сложная конструкция).
LayerSettings (разные документы - разные настройки
Роль LayerSettings во всём этом деле для меня осталась загадкой. Это подмножество LayoutMap, с которым работают в данный момент? При этом
Есть документ с кучей электронных карт (участки, дороги, светлофоры, проч).
на каждый вид объектов, размещаемых на карте, существует отдельный LayoutMap?
Собственно о проблеме.
Затем по клику на участок объект класса Yard "собирает" инфу об участке по его ID. Для этого ему нужно знать ID участка (передается) и LayerSettings, чтобы знать, какие слои учавствуют в данном проекте.
"Клик" - это событие. Какой объект обрабатывает это событие? Как разворачивается обработка этого события до посылки сообщения к Yard об участке (ID участка) и настройках (LayerSettings)?
Варианты решения:
1) Тот объект, который посылает сообщение к Yard, вместе с ID участка может передать и требуемый объект LayerSettings.
class Yard
{
public procedure CollectInfo(AreaID, LayerSettings)
}
2) В данной схеме LayoutPassport выглядит как Mediator, поэтому можно в нём разместить метод GetLayerSettings, тем самым перепоручая ему заботу о поиске LayerSettings и организации доступа к этому объекту. Но в этом случае Yard должен иметь ссылку на LayoutPassport.
class LayoutPassport
{
public function GetLayerSettings: LayerSettings
}
class Yard
{
public procedure CollectInfo(AreaID)
{
LayerSettings = LayoutPassport.GetLayerSettings
}
}
P.S. Код чисто условный - не язык программирования, просто схема решения.
