OOP Design Pattern for Graphs

[LAVA 1.0 Content]

Hi,

I need to implement a graph structure in LabVIEW. Each node in the graph can be of any subclass of Graph Object class. No graph object can directly derive from "Graph Object" class but one of its subclasses which define what kind of "Graph Object" we have. Not all "Graph Objects" can have children.

As a structure graph is like a tree but the nodes can have links from one tree structure to the other. You can think of it as a file system directory tree. The file system objects can be of three subtypes: files, folders or shortcuts. Files and folders together form a tree and shortcuts make this tree a graph. Files cannot have subobjects whereas folders can contain multiple subobjects. Shortcuts contain one subobject.

In a general graph there could be recursive references, however that's something that I do not need. So I can do without recursive references from an object back to itself or one of its predecessors.

One additional requirement is that the graph flows i.e. the implementation is pure dataflow and is not implemented using queues or other kinds of globals. This restriction is due to the fact that the problem I'm solving is very computing intensive and I need to get it highly parallel to decrease the computation time.

Now I'd like to ask the community what do you think would be a best possible way to implement graph data structure in LVOOP as pure dataflow. We could contrain to an example of filesystem with shortcuts as I think it is general enough that I can derive the solution to my problem from the solution to the file system problem. The class hierarchy would then look something like this.

• LabVIEW Object
  • File System Object
    • File Object
      
    • Folder Object
      
    • Shortcut Object
      

[LAVA 1.0 Content]

As nobody has yet aswered, I'll try to clarify my problem a bit. Consider a LabVOOP object. It can contain provate data elements. These data elements can be objects or contain objects (e.g. in clusters and arrays) and these objects can further contain private data elements that are objects. Do not confuse term object with term class here.

So the object refer to other objects which refer to other objects and so on. This construct forms a data structure we call a tree. As objects do not share memory in LabVOOP, there are no nodes (objects) in this tree that are children of more than a single other node. Furthermore objects cannot refer to themselves.

What if I need a graph instead of a tree. I'd still like to take advantage of highly parallel nature or by-value LabVOOP. In my main application the wire should always pass the whole graph. When the wire is branched, a copy of the graph should be made. Only when traversing the graph the graph nature should be visible. If I had a copy constructor together with by-reference object I could get by-value implementation of a graph. But I do not, not yet at least.