Search code examples
c#design-patternscomposite

Extending the Composite pattern?

I'm using the Composite pattern to represent a hierarchical data structure:

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

Each Leaf represents a particular task. At first, the user is presented with a default list of tasks for a particular scenario, the user then checks/unchecks certain tasks (e.g. using a TreeView control) and upon accepting the selection, the data is eventaully persisted to an XML file. This data is later used by either (1) an engine that completes the checked tasks or (2) the UI to display list of tasks that have been selected.

In some scenarios, there are certain (complex) tasks that require additional "internal" tasks as prerequisites for the engine to generate the complex task. However I do not wish to display those "internal" tasks to the user, but they are still used by the engine and are written to the XML file.

Knowing that I can have a large number of different scenario types (each scenario has its own XML file), each with a completely different list/arrangement/default selection of tasks, and different "internal" tasks based on certain selections of some tasks, how can I implement the interface between the reading/writing of the XML file and the UI + Engine ? One that hides the "internal" tasks from the UI, yet keeps track of them by writing them to the XML file, and one that allows different customizations on a scenario type basis ?

Solution

  • From what I understand you basically have a list of tasks and these can have sub tasks. So here are my thoughts:

    • All tasks derive from a common task class/interface (no difference between internal or external tasks)
    • Each task has a list of tasks (this would be its internal/sub tasks)
    • This list should also assign attributes to the sub/internal tasks
      (such as whether it's visible or not). Note that a task is not hidden or internal in itself. So such an attribute should not be at the task class level but at the level where one task is associate to another
      task.
    • Also, how UI/Engine wants to process a task should be different from what the tasks are actually. So, UI/Engine specific settings should not be mentioned at the task level.

    I know this is a bit on the abstract side but let me know if this answers your question or if there are any confusions.