Java – Benefits of Using Static Inner Builder Class

java

During the course of writing the code guidelines for a company I found myself recommending using the Builder pattern from Effective Java, instead of telescopic constructors.

However, after thinking about it a bit more, surely a more elegant solution is to just remove the builder class and the also remove the extra constructors with optional arguments.

So just have the one constructor with required parameters, normal getters/setters, and comment the code. When implementing just create a new instance of yr object then set values.

My original thinking was the benefit came from removing the confusion as to what paramters were optional and what were required; however the true benefit comes from using method chaining/fluent interface.

The builder pattern has benefits when you make lots of new instances as the ide can do the leg work and also if there are many (15+) optional parameters. However, is it worth the extra time coding the static inner class, would you recommend using the builder, or is it a waste of time ?

Best Answer

I tend to follow a pattern that constructors should provide all of the mandatory values required to create a valid and consistent object. For optional values, I try to think about what the most common default should be, so that setters are used as little as possible.

If I find that there are lots of optional values or that a larger proportion of optional values tend to be altered from their defaults, then I'll use the builder pattern (static inner builder or other similar design).

Josh generally gives pretty darn good advice - the best thing I like about him is that the advice comes from the trenches - he admits himself that he made mistakes in designing parts of Java, and Effective Java is partly kind of his 'cure' so to speak :-)

Related Solutions

Java – Improvements to Joshua Bloch’s Builder Design Pattern

Your variation is quite nice. But it lets users do this:

Options.Builder builder = new Options.Builder().option1("firefox").option2(1);
Options optionsVariation1 = builder.build();
assert optionsVariation1.getOption1().equals("firefox");
builder.option1("chrome");
assert optionsVariation1.getOption1().equals("firefox"); // FAILURE!

Which rather defeats the object.

You could change the build method to do this:

public Options build() {
    Options options = this.options;
    this.options = null;
    return options;
}

Which would prevent this - any call to a setter method on the builder after the build call will fail with a NullPointerException. If you wanted to be flash, you could even test for null and throw an IllegalStateException or something instead. And you could move that up to a generic base class where it could be used across all builders.

Java Design Patterns – Builder Pattern Inside Interface, Bad Design Decision?

The main problem is that you've created a circular dependency between Person and PersonImpl... Person shouldn't have any references to implementation classes, but the "new PersonImpl()" call in the builder creates a hard, compile-time dependency on the concrete class.

I think the fix is to either spin PersonBuilder off into it's own class, or else move PersonBuilder into PersonImpl. It's a little weird declaring a class inside an interface anyway -- I wouldn't say I've never done that, but it seems preferable to keep interfaces simple.
Passing the Builder as a constructor argument in PersonImpl couples the implementation class really tightly to the builder. You'd be better off keeping a cleaner separation between the builder and the buildee. The builder (obviously) needs to know about PersonImpl, but it would be best if PersonImpl didn't reference the builder.
Do you anticipate having more than one Person implementation? It's looks like a data class, and I'm not sure you need to extract an interface in the first place.
And... as a general pattern, if you're going to create a dozen or so classes like this, I think this pattern would become pretty cumbersome -- there's an interface, implementation, and builder for each class. That seems like a lot of extra code for something that may not need distinct interfaces.

Here's the variation to Builder that Josh Block came up with. It's similar in that it uses an inner class to access & set internal values, so that the class becomes effective immutable. I think the main difference with your code is that there's not a separate interface.

http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html

TL;DR:

the dependencies should go Builder --> Impl --> Interface
omitting the interface and nesting the Builder inside the Impl is a nice way to provide one-time access to the internal impl details, while hiding a circular dependency between builder and impl.

Best Answer

Related Solutions

Java – Improvements to Joshua Bloch’s Builder Design Pattern

Java Design Patterns – Builder Pattern Inside Interface, Bad Design Decision?

Related Topic