Un StringBuilder è simile a un Pattern Builder, ma non condivide molto con la descrizione GoF di questo modello di progettazione. Il punto originale del modello di progettazione era
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.
(nota: "complesso" significa principalmente "composto da più parti", non necessariamente "complicato" o "difficile")
Le "diverse rappresentazioni" sono fondamentali qui. Per 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 un HtmlDocument o un TexDocument o un MarkdownDocument a seconda dell'implementazione concreta fornita:
class HtmlDocumentBuilder implements ArticleBuilder {
...
HtmlDocument getResult();
}
HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();
Quindi un punto centrale del pattern Builder è polymorphism . Il libro Design Patterns confronta questo modello con Abstract Factory:
Abstract Factory is similar to the Builder in that it too may construct complex objects. The primary difference is that the Builder pattern focuses on constructing a complex object step by step. […] Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.
Questo aspetto passo dopo passo è diventato l'aspetto più popolare del pattern Builder, in modo che nel linguaggio comune il pattern Builder sia interpretato in questo modo:
Split construction of an object into multiple steps. This allows us to use named arguments or optional parameters even in languages that do not support these features.
Wikipedia definisce il modello in questo modo:
The builder pattern is an object creation software design pattern. Unlike the abstract factory pattern and the factory method pattern whose intention is to enable polymorphism, the intention of the builder pattern is to find a solution to the telescoping constructor anti-pattern[citation needed]. […]
The builder pattern has another benefit. It can be used for objects that contain flat data (html code, SQL query, X.509 certificate...), that is to say, data that can't be easily edited. This type of data cannot be edited step by step and must be edited at once. The best way to construct such an object is to use a builder class.[citation needed]
— from Builder Pattern on Wikipedia, by various contributors.
Quindi, come possiamo vedere, non esiste una comprensione veramente comune di quale modello si riferisca a questo nome, e in alcuni punti definizioni diverse persino si contraddicono a vicenda (ad esempio riguardo alla rilevanza del polimorfismo per i Costruttori).
L'unica proprietà comune di StringBuilder con varie interpretazioni del modello è che il prodotto viene creato passo dopo passo anziché in una volta. Non soddisfa una lettura rigorosa della definizione GoF del modello di progettazione, ma si ricorda che i modelli di progettazione sono concetti malleabili destinati a facilitare la comunicazione. Continuo a chiamare StringBuilder un esempio di Builder Pattern, anche se atipico: la ragione principale per cui la struttura in Java è la concatenazione performante in presenza di stringhe immutabili, ma non alcuni interessanti progetti orientati agli oggetti.