Pattern Composite

Summary Un design pattern che permette di usare uniformemente oggetti singoli e oggetti composti senza bisogno di if.

Conosciuto anche come

No ha altri nomi.

Intento

Il design pattern Composite compone degli oggetti in una struttura ad albero facendo in modo che l'utilizzatore (Client) possa usare indifferentemente gli oggetti singoli (Leaf) e quelli composti (Composite).

La struttura ad albero (con nodi Component) viene creata a run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Strutturali.

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

Quando c'è la necessità di rappresentare una gerarchia di oggetti parti-tutto dove un oggetto che rappresenta il tutto (Container) contiene diverse parti (Leaf o a sua volta un altro Container) può essere usato il design pattern Composite.

Quando c'è una gerarchia di oggetti ed il codice della applicazione è complesso perché deve distinguere gli oggetti foglia (Leaf) da quelli contenitore (Container) e trattarli in maniera distinta il design pattern Composite permette all'utilizzatore (Client) di ignorare le differenze e quindi di usare tutti gli oggetti in maniera uniforme semplificando l'applicazione.

Il punto centrale del design pattern Composite è che astrae i nodi foglia (Leaf) e quelli composti (Composite) in una classe base comune (Component).

Esempi d'uso in .NET

Un esempio d'uso in .NET è la classe System.Web.UI.Control che corrisponde a Component che ha la collezione Controls da cui sono disponibili le operazioni di Add, Remove e GetChild mentre i metodi RenderControl o DataBind corrispondono al metodo Operation. Lo stesso vale per System.Windows.Forms.Control .

Un altro esempio è System.ComponentModel.Component che corrisponde a Component con la property Container di tipo IContainer da cui si ha accesso alla collezione Components con Add e Remove e l'accesso ai nodi figli menter in Component il metodo Dispose e la property Site hanno il ruolo di Operation.

Note sulla implementazione in .NET

.NET ha un sistema automatico di Garbage Collection, questo risolve il problema di rilascio degli oggetti con risorse managed e quindi nell'implementazione di questo design pattern non è necessario individuare chi è responsabile del rilascio di un nodo figlio. In caso di risorse unmanaged che richiedono di seguire il pattern del dispose va determinato il responsabile del rilascio di ogni oggetto.

Per la rappresentazione della collezione dei nodi figli, possono essere scelte una qualunque delle collezioni di tipo IList.

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Il PatternCommand può essere usato per chreare dei comandi che si ottendono componendo più comandi singoli, per comporre i più comandi può essere usato il design pattern Composite.
Il PatternVisitor localizza le operazionied il comportamento che altrimenti dovrebbe essere distribuito tra le classi Leaf e Composite.
Quando i nodi figli devono essere ordinati, il PatternIterator può essere utilizzato per definire un ordinamento.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

La classe Component deve rappresentare tanto le operazioni di Leaf che di Container, questo contrasta con la regola per cui una classe deve definire solo operazioni che hanno senso per quella classe. La fantasia è l'unico strumento per individuare un insieme comune di metodi (e relativi nomi) che siano significativi tanto per Leaf che per Container. Questo vale in particolare per i metodi tipici di Composite (Add, Remove, GetChild) che un utilizzatore (Client) potrebbe eseguire su una Leaf e dovrebbe ricevere un risultato valido e significativo.
La capacità di Component di rappresentare sia le classi Leaf che Container deriva dalla sua generalità, il rovescio della medaglia è che questa generalità non permette di usare la tipizzazione forte per vincolare i tipi che sono accettabili in qualità di Component per una data gerarchia, resta solo la verifica a run-time.
Se Component può avere più contenitori a cui appartiene, la gestione risulta più complicata.

Domande di approfondimento

In che modo il design pattern Composite aiuta a organizzare la logica condizionale della applicazione (es. gli if)?
Nel caso in cui se gli oggetti che hanno figli sono pochi e la maggior parte degli oggetti sono foglie, ha senso usare il design pattern Composite?
Che similitudini ci sono lo PatternFlyweight? E quali differenze?

Link

VediAnche CatalogoDeiDesignPattern