Am I overusing trees as a model or are they just very common?

Question

I'm working on a project and I've found that I've modeled the two largest components as trees.

My main uses so far are:

1. Generically model physical containers (and sub containers, sub sub containers etc)
2. Model liquid samples (and sub samples, and sample derivatives - and subs of those, etc)

I now need to model some events based on the shipment of samples e.g. collected at location X, when arrive at processing centre do Y

It now seems natural to model the events as a tree to denote which events follow on from others.

I'm starting to wonder if I am just seeing trees everywhere because I want to, or if its a legit approach?

Edit To Answer Some Points Raised

Everyone seems to agree with trees for the containers.

For the liquid samples, although there are various types - what I really need to track is parentage so that given any sample, I can quickly find all things that derived from it in some way. I have been told I can assume that samples will not be combined so all sub samples (or derivatives) will have only 1 parent.

As to the events, yeah I think I was just going for a tree for ease. It doesn't make much sense to me after reading comments and further thought.

Thanks all for the input.

Answer 1

It's a legit approach when you have data that can be nested very deeply/recursively, such as physical containers or for hierarchical data (such as a corporate organization tree, or a filesystem). Your second example may or may not fit tree-models as nicely but I'm not sure since I don't know how different a sub sample is from a sample derivative.

Shipments of samples from locations, there only seems to be three levels to this tree: The sample, the location it's from, and the processing center. It may or may not make sense to arrange the hierarchy in this fashion (you'd know better). If you're worried about tree-overuse, you could use nested hashmaps or something like that. Even if you don't use trees internally, they are still good for UI displays of this sort of data.

Answer 2

You have to do what works for you.

If you think that you can better understand a project and demonstrate it to other people using your methods, there probably the right ones.

Answer 3

Generically model physical containers (and sub containers, sub sub containers etc)

This most certainly seems to fit the Composite Pattern and I see no issues with a tree-style design. Nothing to really add that others haven't already pointed out:

• easily iterated/traversed
• observable hierarchy

Model liquid samples (and sub samples, and sample derivatives - and subs of those, etc)

This doesn't seem to fit a tree-style or composite architecture, IMO. This almost sounds like a good fit for the Prototype Pattern, that is, if I correctly understand #2.

Answer 4

@Frustrated's answer is good. I would only add: think about what you're doing with the information. You should use the structure that has the most simplifying effect on the code you have to write.

Trees are a good useful conceptual structure, but they don't have to be implemented as a typical memory tree structure. Issues of memory or time efficiency only matter if the tree is large or accessed at high frequency. An example of another representation is as a simple linear array/list of records or structures, where each record is marked with its "depth", as in a bill-of-materials or chart-of-accounts.

One question I would ask is - do you have uncle/cousin-type relationships that reach across the hierarchy, like variable names in a program, or relative links in a file structure? If so, you need to think about how to represent those.

Answer 5

Trees are okay if you can guarantee that there should only be one path to an item, i.e., that users will only think of things as being "in" one place. A set of nested containers, sure.

But a hierarchy of liquids--that seems like not as good of a fit. I could imagine wanting to get to a particular derivative starting at different places. In this case I might use a directed acyclic graph instead of a pure tree.