UGIdotNET Home UGIdotNET Home
UGIdotNET Blogs UGIdotNET Blogs
UGIdotNET Forum UGIdotNET Forum
MSDN Architetti MSDN Architetti
Visualizza Modifiche Visualizza Modifiche
Modifica Modifica
Stampa Stampa
Modifiche Recenti Modifiche Recenti
Sottoscrizioni Sottoscrizioni
Ufficio Oggetti Smarriti Ufficio Oggetti Smarriti
Cerca Riferimenti Cerca Riferimenti
Rinomina Rinomina
Cerca

Versioni

31/01/2006 10.01.52
-151.38.0.241
27/12/2005 16.33.55
LucaMinudel-151.47.139.114
27/12/2005 0.42.44
LucaMinudel-151.47.143.118
Elenco completo versioni Elenco completo versioni
Pattern Builder
.
Summary Un design pattern che separa i passi di costruzione di un oggetto complesso dalla sua rappresentazione.

Conosciuto anche come

Non ha altri nomi.

Intento

Il design pattern Builder separa la costruzione (il metodo Construct dell'oggetto Director è l'algoritmo di costruzione che compone le parti e ogni metodo di ConcreteBuilder costruisce una parte) di un oggetto complesso dalla sua rappresentazione (Product) in modo tale che lo stesso processo di costruzione (il metodo Construct dell'oggetto Director) possa essere usato per creare diverse rappresentazioni (per ogni rappresentazione ci sarà un suo ConcreteBuilder che produce un diverso Product).

La classe ConcreteBuilder che costruisce le parti dell'oggetto è stabilito a run-time quindi design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Creazionali.

Diagramma UML

Un'altro diagramma equivalente qui e qui .

Motivazione

Quando l'algoritmo di costruzione (il metodo Construct dell'oggetto Director) di un oggetto (Product) è complesso diventa utile separare l'algoritmo di costruzione (il metodo Construct dell'oggetto Director) dalla creazione delle singole parti che compongono l'oggetto (ogni metodo BuildPartA, BuildPartB,...BuildPartZ di ConcreteBuilder costruisce una parte).

Anche quando si desidera poter creare diverse rappresentazioni di un oggetto (Product), per esempi se l'oggetto è il documento di help e si desidera crearlo in Html, in Chm o in RTF (HtmlProduct, ChmProduct e RtfProduct) è utile poter sostituire la costruzione di una rappresentazione (per esempio HtmlConcreteBuilder, ChmConcreteBuilder o RtfConcreteBuilder) senza dover modificare l'algoritmo di creazione (il metodo Construct dell'oggetto Director). Lo stesso vale quando si desidera poter cambiare facilmente la rappresentazione interna di un oggetto (Product) col minimo sforzo (ossia variando solo il metodo di ConcreteBuilder corrispondente alla parte che si vuole modificare e senza bisogno di intervenire su Director).

In questi casi il design pattern Builder viene in aiuto.

Esempi d'uso in .NET

Ecco due esempi parziali d'udo del builder in .NET.

Un esempio d'uso è nella serializzazione del Remoting di .NET dove l'interfaccia IFormatter definisce il builder e i due concrete builder sono SoapFormatter e BinaryFormatter. L'oggetto costruito è lo stream su cui viene serializzato l'oggetto che in un caso contiene una rappresentazione XML e nell'altra una rappresentazione binaria. Questo esempio sfrutta la possibilità di variare la rappresentazione ma non sfrutta la possibilità di separare l'algoritmo infatti IFormatter contiene un solo metodo per la costruzione (ossia la costruzione avviene in un solo passo) e non c'è un Director che contiene l'algoritmo.

Un'altro esempio è il System.CodeDom.Compiler.ICodeGenerator è l'interfaccia del builder mentre i diversi concrete builder sono resi disponibili dal metodo CreateGenerator di CSharpCodeProvider, VBCodeProvider e JScriptCodeProvider. Valgono le stesse considerazioni per IFormatter.

Note sulla implementazione in .NET

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Il design pattern Builder viene spesso usato per costruire l'oggetto Composite del PatternComposite.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Il design pattern Builder permette un controllo fine sul processo di costruzione dell'oggetto e di conseguenza sulla struttura interna dell'oggetto che viene creato.

Il builder volutamente non è una interfaccia ma è una classe base con metodi virtual e non abstract che non fanno nulla in modo tale che il ConcreteBuilder possa fare l'override solo per le parti che lo interessano ignorando le altre (per esempio un builder di testo ASCII può ignorare la dichiarazine di Font, colori, etc.).

Domande di approfondimento

  • In cosa il PatternAbstractFactory è simile al design pattern Builder? E qual'è la differenza principale?
  • In che modo il design pattern Builder ti permette di aggiungere una parte all'oggetto creato (un metodo a Builder) senza dover modificare tutti i ConcreteBuilder?

Link

VediAnche CatalogoDeiDesignPattern

UGIdotNETWiki

UGIdotNETWiki è il WikiWiki italiano dedicato a .NET

Se è la prima volta che senti parlare di Wiki, leggi il BenvenutoAiVisitatori e WikiInUnMinuto, oppure il ManualePassoPassoDelWiki.

Argomenti Recenti

  • PatternBuilder
© 2008 User Group Italiano UGIdotNET. Tutti i diritti riservati. Note legali