A new one?!
“patterns allow developers to communicate using well-known, well understood names for software interactions”
Giving the same name to a different design is just plain Stupid….

thank you!

I only had to complement your implementation. Although in general I prefer to avoid mutability in compile time, I haven’t found a simple way to do it that didn’t imply duplicating fields, so I chose this runtime check, which is a reasonable balance, in my opinion.

Regards,

Xavi

Please see also Xavi Miró’s great Blog entry here.

@Xavi Miró
Great idea how to ensure immutability and i appreciate that you like my implementation

yes, you’re right, this implementation can’t ensure immutability. You can use duplication of fields as Josh does, or you can complement this implementation throwing exceptions when trying to build more than once the object and when trying to modifiy the object after it’s been built. I prefer doing the latter, because I don’t like duplicating fields. I have complemented this implementation in my blog, here.

Regards,

Xavi

this is not the builder pattern. The builder pattern is used to compose a set of objects in a certain way. E.g. create a “document”, place a “title” and add a “paragraph”.

In your example you only create one singel object (not a graph of objects) and you also use one concrete type for this object.

On the first glance your example indeed looks a bit like a builder but what you do there is writing a “fancy contructor”.

A builder would work independent of the concrete object types and usually compose a graph, e.g. a document containing a title and a paragraph. The document and its nested objects then could be instances of HTMLDocumnet, HTMLTitle and HTMLParagraph in one case or RTFDocument, RTFTitle and RTFParagraph in the other case.

Code using the builder would probably look like this:
builder.start(); // get the builder ready to create a new document … alternatively create a new builder
builder.setTitle(”my title”);
builder.addParagraph(”my first paragraph”);
builder.addParagraph(”my second paragraph”);
builder.getDocument(); // construct and _compose_ a document

Usually the point where the builder is used, has no knowledge wether an RTF or an HTML document is “builded”.

Your example always knows and only can create ID3Tags … therefor it is not the builder pattern.

ID3Tag.Builder builder = new ID3Tag.Builder(”Bad”, “U2″).comment(”not bad”);
ID3Tag myTag = builder.build();
builder.comment(”very bad!”);

Here the myTag instance has been changed through builder, whereas in Bloch’s example the builder has separate instance vars and the build() method creates a new instance each time it’s called.

You are right that i changed the original version a little bit. The reason is that i just did not want to repeat myself. Meaning that i did not want to have the same members in the outer and inner class as the original version does it.

The pro of this method is that if you add an additional member you do not need to type it twice. Furthermore, i think the members are logically correct belonging to the outer class but are not “correct” members for the builder itself.
The con of this variant is - as you already mentioned - that you cannot do some value consistency checks before constructing the outer object. But that may only be a valid con if the outer object is very expensive to create. In “normal” situations it´s totally o.k. to do the consistency checks in the build method and to throw an Exception for example IllegalArgumentException if some precondition is not met.

Any other con`s you can think of?