Sto sfruttando gli alberi come un modello o sono solo molto comuni?

È un approccio legittimo quando si dispone di dati che possono essere annidati molto profondamente / in modo ricorsivo, come contenitori fisici o dati gerarchici (come una struttura organizzativa aziendale o un filesystem). Il tuo secondo esempio può o non può adattarsi bene ai modelli ad albero, ma non sono sicuro poiché non so quanto sia diverso un sottocampione da una derivata del campione.

Spedizioni di campioni da località, sembra che ci siano solo tre livelli su questo albero: il campione, la posizione da cui proviene e il centro di elaborazione. Potrebbe avere o meno senso organizzare la gerarchia in questo modo (lo sapresti meglio). Se sei preoccupato per l'uso eccessivo degli alberi, potresti usare le hashmap nidificate o qualcosa del genere. Anche se non si utilizzano gli alberi internamente, sono comunque validi per i display dell'interfaccia utente di questo tipo di dati.

Devi fare ciò che funziona per te.

Se pensi di poter capire meglio un progetto e mostrarlo ad altri usando i tuoi metodi, probabilmente ce ne sono di quelli giusti.

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

Questo sicuramente sembra adattarsi al Pattern Composito e non vedo problemi con un design in stile albero. Nulla da aggiungere davvero che altri non abbiano già indicato:

• facilmente iterato / attraversato
• gerarchia osservabile

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

Questo non sembra adattarsi ad un'architettura ad albero o composito, IMO. Questo suona quasi come una buona idea per il Prototype Pattern , cioè, se ho capito bene # 2.

@ La risposta di Frustrated è buona. Vorrei solo aggiungere: pensa a cosa stai facendo con le informazioni. Dovresti usare la struttura che ha l'effetto più semplice sul codice che devi scrivere.

Gli alberi sono una buona struttura concettuale utile, ma non devono essere implementati come una tipica struttura ad albero della memoria. Problemi di memoria o di efficienza temporale sono importanti solo se l'albero è grande o se si accede ad alta frequenza. Un esempio di un'altra rappresentazione è un semplice array lineare / elenco di record o strutture, in cui ogni record è contrassegnato con la sua "profondità", come in una distinta materiali o in un piano dei conti.

Una domanda che vorrei porre è: hai relazioni di tipo zio / cugino che raggiungono la gerarchia, come i nomi di variabili in un programma, o collegamenti relativi in una struttura di file? Se è così, devi pensare a come rappresentarli.

Gli alberi vanno bene se puoi garantire che ci debba essere solo un percorso per un oggetto, cioè che gli utenti pensino solo a cose come "in" un posto. Una serie di contenitori annidati, certo.

Ma una gerarchia di liquidi - che sembra non essere una buona idea. Potrei immaginare di voler arrivare a un derivato particolare partendo da luoghi diversi. In questo caso potrei usare un grafico aciclico diretto invece di un albero puro.