views:

26

answers:

1

I have a custom tree data class, following the standard Composite pattern. I obviously don't want the GUI and the model to be too closely tied, so the GUI should be an Observer of the model, and changes should be done through the model layer. I'm implementing observable support using C# events - so far, so good, and I have a working system.

  1. Which events would you expect an observable tree to generate? NodeCreate, NodeDelete, NodeMove?
  2. Would you create a single TreeChange event and encode change information in a TreeChangeEventArgs, or would you create one event per update type (possibly along with specific EventArg classes for each)?
  3. NodeDeleting or NodeDeleted? Without getting the deleted Node as argument, NodeDeleted seems of very limited use to me? Of course the tree could fire the NodeDeleted event before (possibly) disposing the Node, but is it good practice throwing a (at least conceptually) deleted Node around?
  4. When deleting a Node containing subnodes, would you expect getting a single NodeDeleted event, or recursive NodeDeleted for the subnodes as well? A single NoteDeleted seems fine to me, but perhaps there's some cases I haven't considered.
  5. Changes of the individual nodes, as opposed to changes to the tree structure. I assume this is best handled by having the individual nodes observable? (I'm currently handling this with INotifyPropertyChanged on the node classes).
  6. No, I don't want to use a Windows.Forms.TreeView as my main data structure :)

And, the bonus question: let clients directly manipulate tree nodes and have the tree itself fire events, or do something along the lines of Service.Instance.AddNode(parentNode, "New node name") and have the Service class responsible for generating events?

A: 
  1. Definitely I would add NodeChange, what use would a tree be without ability to store values in nodes? Other events depend on what everything the tree should support, e.g. for self-balancing trees you might use NodeRotate events etc. Definitely allow introduction of custom events for future purposes.
  2. I would prefer a design based on OO principles, like polymorphic behaviour, so different subclass is my answer.
  3. This event is important for UI, simple solution to your dilemma is to add some sort of id to nodes, so a deleted node in tree model can be hidden in the UI.
  4. Depends on your deletion semantics, e.g. you might want to delete single node and connect all its subnodes to a parent node of the deleted node. However single recursive delete seems more reasonable for composite structures.
  5. You have to consider what the relation between a node and a tree is. I would prefere special events for nodes, which would generate tree events when needed.
  6. I am not a .Net guy, but always consider if what is readily available cannot be adjusted to meet your requirements.

Bonus: I think the behaviour belonging to tree should be in the tree, to change it you have polymorphism and inheritance, do not use structural designs where OO makes more sense in an OO system.

Gabriel Ščerbák