Расширяете составной паттерн? - PullRequest
Новая
       29

Расширяете составной паттерн?

0 голосов
/ 06 марта 2012

Я использую Составной шаблон для представления иерархической структуры данных:

  • CompositeNodeA
    • Leaf1
    • Leaf2
    • ...
  • CompositeNodeB ....

Каждый Лист представляет определенную задачу. Сначала пользователю предоставляется список задач по умолчанию для конкретного сценария, затем пользователь проверяет / снимает отметку с определенных задач (например, используя элемент управления TreeView), и после принятия выбора данные даже полностью сохраняются в файле XML. Эти данные позже используются либо (1) механизмом, выполняющим проверенные задачи, либо (2) пользовательским интерфейсом для отображения списка выбранных задач.

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

Зная, что у меня может быть большое количество различных типов сценариев (каждый сценарий имеет свой собственный файл XML), у каждого из которых есть совершенно другой список задач / порядок расположения / выбор по умолчанию, а также различные "внутренние" задачи, основанные на определенных вариантах выбора. некоторые задачи, как я могу реализовать интерфейс между чтением / записью XML-файла и UI + Engine? Тот, который скрывает «внутренние» задачи от пользовательского интерфейса, но отслеживает их, записывая их в файл XML, и тот, который допускает различные настройки на основе типа сценария?

1 Ответ

1 голос
/ 06 марта 2012

Из того, что я понимаю, у вас в основном есть список задач, и у них могут быть подзадачи.Итак, вот мои мысли:

  • Все задачи происходят из общего класса / интерфейса задач (без разницы между внутренними и внешними задачами)
  • Каждая задача имеет список задач (это будетбыть его внутренними / подзадачами)
  • Этот список должен также назначать атрибуты под / внутренним задачам
    (например, является ли он видимым или нет).Обратите внимание, что задача не является скрытой или внутренней сама по себе.Таким образом, такой атрибут должен быть не на уровне класса задач, а на уровне, где одна задача связана с другой задачей
    .
  • Кроме того, то, как UI / Engine хочет обработать задачу, должно отличаться от того, чтозадачи на самом деле.Таким образом, специфические настройки пользовательского интерфейса / движка не должны упоминаться на уровне задач.

Я знаю, что это немного абстрактно, но дайте мне знать, если это отвечает на ваш вопрос или есть какие-то недоразумения.

...