Наблюдаемое дерево - каких событий ожидать? - PullRequest
2 голосов
/ 09 сентября 2010

У меня есть собственный класс данных дерева, соответствующий стандартному шаблону Composite .Я, очевидно, не хочу, чтобы графический интерфейс и модель были слишком тесно связаны, поэтому графический интерфейс должен быть Observer модели, и изменения следует вносить через уровень модели.Я реализую наблюдаемую поддержку с использованием событий C # - пока все хорошо, и у меня есть работающая система.

  1. Какие события вы ожидаете генерировать наблюдаемое дерево?NodeCreate, NodeDelete, NodeMove?
  2. Вы бы создали одно TreeChange событие и закодировали бы информацию об изменениях в TreeChangeEventArgs, или вы бы создали одно событие для каждого типа обновления (возможно, вместе с конкретными классами EventArg для каждого)?
  3. NodeDeleting или NodeDeleted?Без получения удаленного узла в качестве аргумента NodeDeleted кажется мне очень ограниченным?Конечно, дерево может запустить событие NodeDeleted до (возможно) удаления узла, но является ли хорошей практикой бросать (хотя бы концептуально) удаленный узел вокруг?
  4. При удаленииУзел, содержащий подузлы, ожидаете ли вы получить одно событие NodeDeleted или рекурсивное NodeDeleted для подузлов?Один NoteDeleted кажется мне подходящим, но, возможно, есть некоторые случаи, которые я не рассматривал.
  5. Изменения отдельных узлов, в отличие от изменений в древовидной структуре.Я предполагаю, что это лучше всего обрабатывать, наблюдая отдельные узлы?(В настоящее время я обрабатываю это с INotifyPropertyChanged для классов узлов).
  6. Нет, я не хочу использовать Windows.Forms.TreeView в качестве основной структуры данных:)

И бонусный вопрос: позволить клиентам напрямую манипулировать узлами дерева и запускать события самим деревом, или делать что-то вроде Service.Instance.AddNode(parentNode, "New node name") и иметь класс Service, отвечающий за генерацию событий?

1 Ответ

0 голосов
/ 10 сентября 2010
  1. Определенно, я бы добавил NodeChange. Каким будет использование дерева без возможности хранить значения в узлах?Другие события зависят от того, что все дерево должно поддерживать, например, для самоуравновешивающихся деревьев вы можете использовать события NodeRotate и т. Д. Определенно разрешить введение пользовательских событий для будущих целей.
  2. Я бы предпочел проект, основанный на принципах ОО,как и полиморфное поведение, таким ответом является другой подкласс.
  3. Это событие важно для пользовательского интерфейса, простое решение вашей дилеммы - добавить некоторый вид идентификатора к узлам, чтобы удаленный узел в древовидной модели можно было скрыть вUI.
  4. Зависит от вашей семантики удаления, например, вы можете удалить один узел и подключить все его подузлы к родительскому узлу удаленного узла.Тем не менее, для составных структур более целесообразно использовать однократное рекурсивное удаление.
  5. Вы должны рассмотреть, какова связь между узлом и деревом.Я бы предпочел специальные события для узлов, которые генерировали бы события дерева при необходимости.
  6. Я не парень .Net, но всегда думаю, нельзя ли настроить то, что доступно, для удовлетворения ваших требований.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...