A StringBuilderè simile al modello Builder, ma non condivide molto con la descrizione GoF di questo modello di progettazione. Il punto originale del modello progettuale era
Separare la costruzione di un oggetto complesso dalla sua rappresentazione in modo che lo stesso processo di costruzione possa creare rappresentazioni diverse.
- da Design Patterns , di Gamma, Helm, Johnson, Vlissides.
(nota: "complesso" significa principalmente "composto da più parti", non necessariamente "complicato" o "difficile")
Le "diverse rappresentazioni" è la chiave qui. Ad esempio, assumendo questo processo di costruzione:
interface ArticleBuilder {
void addTitle(String title);
void addParagraph(String paragraph);
}
void createArticle(ArticeBuilder articleBuilder) {
articleBuilder.addTitle("Is String Builder an application of ...");
articleBuilder.addParagraph("Is the Builder Pattern restricted...");
articleBuilder.addParagraph("The StringBuilder class ...");
}
potremmo finire con una HtmlDocumento una TexDocumento una a MarkdownDocumentseconda di quale implementazione concreta è fornita:
class HtmlDocumentBuilder implements ArticleBuilder {
...
HtmlDocument getResult();
}
HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();
Quindi un punto centrale del modello del costruttore è il polimorfismo . Il libro Design Patterns confronta questo modello con la Fabbrica astratta:
La Fabbrica astratta è simile al Costruttore in quanto anch'essa può costruire oggetti complessi. La differenza principale è che il modello Builder si concentra sulla costruzione passo dopo passo di un oggetto complesso. […] Il costruttore restituisce il prodotto come passaggio finale, ma per quanto riguarda la Fabbrica astratta, il prodotto viene restituito immediatamente.
- da Design Patterns , di Gamma, Helm, Johnson, Vlissides.
Questo aspetto passo dopo passo è diventato quindi l'aspetto più popolare del modello Builder, in modo che nella forma comune il modello Builder sia compreso in questo modo:
Dividi la costruzione di un oggetto in più passaggi. Questo ci consente di utilizzare argomenti denominati o parametri opzionali anche in lingue che non supportano queste funzionalità.
Wikipedia definisce lo schema in questo modo:
Il modello builder è un modello di progettazione software per la creazione di oggetti. A differenza del modello di fabbrica astratto e del modello di metodo di fabbrica la cui intenzione è di abilitare il polimorfismo, l'intenzione del modello di costruttore è quella di trovare una soluzione all'antimetro del costruttore telescopico [citazione necessaria] . [...]
Il modello del costruttore ha un altro vantaggio. Può essere utilizzato per oggetti che contengono dati flat (codice html, query SQL, certificato X.509 ...), vale a dire dati che non possono essere facilmente modificati. Questo tipo di dati non può essere modificato passo dopo passo e deve essere modificato contemporaneamente. Il modo migliore per costruire un tale oggetto è usare una classe builder. [citazione necessaria]
- da Builder Pattern su Wikipedia , da vari collaboratori.
Come possiamo vedere, non esiste una comprensione veramente comune di quale modello si riferisca questo nome, e in alcuni punti definizioni diverse si contraddicono persino a vicenda (ad esempio per quanto riguarda la rilevanza del polimorfismo per i costruttori).
L'unica proprietà comune del StringBuildercon varie interpretazioni del modello è che il prodotto viene creato passo dopo passo anziché in una volta sola. Non soddisfa una lettura rigorosa della definizione GoF del modello di progettazione, ma si noti che i modelli di progettazione sono concetti malleabili intesi a facilitare la comunicazione. Continuerei a chiamare StringBuilderun esempio del Builder Pattern, anche se atipico - il motivo principale di quella struttura in Java è la concatenazione performante in presenza di stringhe immutabili, ma non un interessante design orientato agli oggetti.