ciao,
mi chiedo se posso applicare il composite pattern nel caso di una rubrica telefonica dove ciascuna VoceRubrica può essere un Contatto o un Gruppo il quale può contenere a sua volta altri oggetti VoceRubrica.
Un Contatto può, a sua volta, far parte di più Gruppi.


Infine, dovendo memorizzare tale struttura gerarchica nel db, come fareste? una tabella per ciascuna classe concreta (Contatto e Gruppo)? o una tabella unica (VoceRubrica) per l'intera gerarchia di classi co una secnda tabella ContattoGruppo per mantenere la relazione m:n tra le voci rubrica?

Sono dovuta andare a cercare che cos'è il Composite Pattern, per capire cosa stai chiedendo e data un'occhiata superficiale mi pare che sia un pattern per creare oggetti di tipo gerarchico.

Per quanto tu indichi che vorresti strutturare la rubrica con oggetti di tipo VoceRubrica che sono Contatti/Persone oppure Gruppi,
non so se puoi definirla una struttura ad albero.

Normalmente in una rubrica, ogni contatto può far parte di più gruppi, ogni gruppo contiene più contatti, ma un gruppo non contiene altri gruppi.

A meno che tu non ritenga logico inserire gruppi nei gruppi, in questo caso però non vedo un uso utilizzabile di questo tipo di struttura per una rubrica telefonica, se non creare delle ricorsioni per fare impazzire i programmatori.

Pertanto la risposta alla tua domanda è:
dipende, se vuoi fare gruppi di gruppi di gruppi, allora si usa il composite pattern, altrimenti hai una situazione Master Detail molto semplice ed il composite pattern per quanto applicabile non è detto sia la strada migliore.

Quanto alla rappresentazione sul Database, puoi benissimo utilizzare una sola tabella per Contatti/persone/gruppi, ponendo un TipoVoceRubrica che li identifichi, ma per il collegamento molti a molti si, hai bisogno di una tabella di appoggio dove mettere
IDVocePadre, IDVoceFiglio
collegando un contatto ad un gruppo.

Saluti
Sabrina

Per quanto io sia un appassionato di patterns xD non so rispondere alla tua domanda, però se mi chiedi come farei io, io userei un file xml e aggiungerei nodi di tipo Area e Articolo a un nodo principale Contenuti, che potrai chiamare come vorrai (invece che Contenuti), anche le varie aree le chiameari come vorrai (invece che Area) e potranno contenere altre sotto aere ognuna delle quali potrà avere il suo nome proprio. L' importante è che distingui la root Contenuti, le Aree e le Sottoaree con un attributo, per es. "Tipo="Area". Quando aggiungerai un articolo caratterizzerai il nodo come "Tipo="Articolo" e a questo nodo aggiungerai tutti i suoi contenuti (che possono essere quelli di un contatto di una rubrica telefonica, o delle pagine di un sito, o altro ancora). Un nodo di Tipo="Area" potrà contenere quante sottoaree diverse vorrai e quanti articoli diversi vorrai, ogni sottoarea potrà fare lo stesso, ma un articolo non potrà contenere nient' altro che i suoi contenuti (non potra contenere cioè altri nodi di Tipo="Articolo" e tantomeno altri nodi di Tipo="Area").

Spero di aver reso l' idea almeno un pochino ^^'