A StringBuilder
is similar to a the Builder Pattern, but does not share much with the GoF description of this design pattern. The original point of the design pattern was
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.
(note: “complex” primarily means “composed of multiple parts”, not necessarily “complicated” or “difficult”)
The “different representations” is key here. E.g. assuming this construction process:
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 ...");
}
we might end up with a HtmlDocument
or a TexDocument
or a MarkdownDocument
depending on what concrete implementation is provided:
class HtmlDocumentBuilder implements ArticleBuilder {
...
HtmlDocument getResult();
}
HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();
So one central point of the Builder pattern is polymorphism. The Design Patterns book compares this pattern to the 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.
This step-by-step aspect has then become the more popular aspect of the Builder pattern, so that in common parlance the Builder pattern is understood like this:
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 defines the pattern like this:
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.
So as we can see, there is no truly common understanding of which pattern this name refers to, and in some points different definitions even contradict one another (e.g. regarding the relevance of polymorphism for Builders).
The only common property of the StringBuilder
with various interpretations of the pattern is that the product is created step by step rather than in one go. It does not meet a strict reading of the GoF definition of the design pattern, but please note that design patterns are malleable concepts meant to facilitate communication. I would continue to call StringBuilder
an example of the Builder Pattern, albeit an atypical one – the main reason for that structure in Java is performant concatenation in the presence of immutable strings, but not some interesting object-oriented design.
Best Answer
There a few options the way I see it:
Option 1: Pass the Builder Around
There's no benefit in actually building and returning an object that will need to changed. Just pass the
Builder
object where ever it needs to go and provide access to its fields so that whatever needs to happen between each build stage can know the current state of the builder. The downsides to this are that you cant "lock in" a part of theBuilders
state if that is something you need to do. It can technically be done by having a functionlockInStage1()
or something which changes a flag that stops some setters from being used, but thats a bit messy.Option 2: Provide a ReadOnly implementation
This is basically the same thing as Option 1, but without the
Builder
object. Just have a mutable version of the object and then allow the user to create a immutable version from it.For example:
Personally, I prefer this over the builder pattern as it leaves you open to having a mutable object if it is ever needed, and why have a
Builder
class if the object isn't being built as one piece. It has the same disadvantage as Option 1 though. You can't really lock in the state of each stage.Option 3: Builder for each Stage
Instead of a single object and
Builder
counterpart you would simply make an object for each stage and build it individually. TheBuilder
for each stage would then take as a parameter the previous stage.I don't love this, because you can potentially need to create a lot of classes. However there are some real benefits to this method.
Each stage is locked in. Once it is created it can't be changed.
If you need to add stages between 2 existing stages its fairly simple (kind of like how adding an object to a
LinkedList
has very little overhead. For that reason the stage objects shouldn't be calledStage
,Stage2
or any ordinal value as it would force you to rename all of them.Summary
Overall I would say if the stages need to be locked in go with the Multiple Builders as long as you don't need to change any data in a previous stage once it is created. It can be done, but its fighting the pattern.
If the data in each stage can potentially be changed by what happens in later stages go with passing the
Builder
or providing a ReadOnly version of the object.