У меня есть два типа клиентов, « наблюдатель „-типа и“ Тема » -типа. Они оба связаны с иерархией групп .
Обозреватель будет получать (календарь) данные из групп, с которыми он связан, в разных иерархиях. Эти данные рассчитываются путем объединения данных из «родительских» групп группы, пытающейся собрать данные (каждая группа может иметь только одного родителя ).
Субъект сможет создавать данные (которые получат наблюдатели) в группах, с которыми он связан. Когда данные создаются в группе, все «потомки» группы также будут иметь данные, и они смогут создавать свои собственные версии определенной области данных , но все же будут связаны с созданными исходными данными (в В моей конкретной реализации исходные данные будут содержать период (ы) времени и заголовок, в то время как подгруппы определяют остальную часть данных для получателей, непосредственно связанных с их соответствующими группами).
Однако, когда субъект создает данные, он должен проверить, есть ли у всех затронутых наблюдателей какие-либо данные, которые конфликтуют с этим, что, насколько я понимаю, означает огромную рекурсивную функцию.
Поэтому я думаю, что это может быть сведено к тому факту, что мне нужно иметь иерархию, в которой вы можете перемещаться вверх и вниз , и в некоторых местах можно рассматривать их как единое целое (рекурсия, в основном).
Кроме того, я не просто стремлюсь к решению, которое работает. Я надеюсь найти решение, которое будет относительно простым для понимания (по крайней мере, с точки зрения архитектуры), а также достаточно гибким, чтобы можно было легко получить дополнительные функции в будущем.
Существует ли шаблон проектирования или хорошая практика для решения этой проблемы или аналогичные проблемы иерархии?
РЕДАКТИРОВАТЬ :
Вот дизайн, который я имею:
Класс «Феникс» назван так, потому что я еще не придумал подходящего имени.
Но помимо этого мне нужно иметь возможность скрывать конкретные действия для конкретных наблюдателей , даже если они привязаны к ним через группы.
Немного не по теме :
Лично я чувствую, что должен быть в состоянии разбить эту проблему на более мелкие проблемы, но это ускользает от меня как. Я думаю, это потому, что он включает в себя несколько рекурсивных функций, которые не связаны друг с другом, и разные типы клиентов, которые должны получать информацию по-разному. Я не могу действительно обернуть голову вокруг этого. Если кто-нибудь может подсказать мне, как стать лучше в решении проблем иерархии, я был бы очень рад получить это.
источник
n
с степенью 0, в то время как каждая другая вершина имеет степень не менее 1? Все ли вершины связаны сn
? Является ли путь кn
уникальному? Если бы вы могли перечислить свойства структуры данных и абстрагировать ее операции от интерфейса - списка методов - мы (I) могли бы предложить реализацию указанной структуры данных.O(n)
алгоритмы для четко определенной структуры данных, я могу поработать над этим. Я вижу, вы не использовали никаких методов мутацииGroup
и структуры иерархий. Должен ли я считать, что они будут статичными?Ответы:
Вот простая реализация «Группы», которая позволяет вам перейти к корню и перемещаться по дереву этого корня как к коллекции.
Итак, если у вас есть группа, вы можете пройти по дереву этой группы:
Я надеюсь опубликовать это, показав, как перемещаться по дереву (и развеять его сложность), вы сможете визуализировать операции, которые вы хотите выполнить над деревом, а затем пересмотреть шаблоны самостоятельно, чтобы увидеть что лучше всего подходит.
источник
Из-за ограниченного представления о требованиях к использованию или реализации вашей системы трудно быть слишком конкретным. Например, вещи, которые будут приняты во внимание, могут быть:
Что касается шаблонов и т. Д., Я бы меньше беспокоился о том, какие именно шаблоны возникают в вашем решении, а также о дизайне фактического решения. Я думаю, что знание шаблонов проектирования полезно, но не первостепенное и конечное: если использовать аналогию с писателем, шаблоны проектирования больше похожи на словарь часто встречающихся фраз, а не на словарь предложений, вы должны написать целую книгу из.
Ваша диаграмма выглядит нормально для меня.
Есть один механизм, который вы не упомянули, и который имеет некоторый кеш в вашей иерархии. Очевидно, что вы должны реализовать это с большой осторожностью, но это может значительно улучшить производительность вашей системы. Вот простой пример (предостережение emptor):
Для каждого узла в вашей иерархии сохраняйте унаследованные данные вместе с этим узлом. Делайте это лениво или проактивно, это ваше дело. Когда обновление выполнено в иерархии, вы можете либо заново сгенерировать данные кэша для всех затронутых узлов тут же, либо установить «грязные» флаги в соответствующих местах, и при необходимости ленивые данные будут заново генерироваться при необходимости.
Я понятия не имею, насколько это уместно в вашей системе, но, возможно, стоит подумать.
Также этот вопрос по SO может быть актуален:
/programming/1567935/how-to-do-inheritance-modeling-in-relational-databases
источник
Я знаю, что это «Видимо очевидно», но я все равно собираюсь это сказать, я думаю, вам следует взглянуть на
Observer Pattern
упомянутое вами, что у вас есть Тип наблюдателя и то, что у вас выглядит для меня как образец Наблюдателя.пара ссылок:
DoFactory
oodesign
проверить это. в противном случае я просто кодировал бы то, что вы имеете в своей диаграмме, а затем использовал бы шаблон проектирования для упрощения, если это необходимо. Вы уже знаете, что должно произойти и как программа должна работать. Напишите какой-нибудь код и посмотрите, подходит ли он еще.
источник