9

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 ?

Improve this question
1

2 Answers 2

Reset to default
8

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 :-)

Improve this answer
2
  • 1
    This doesn't say anything about why the inner should be static...
    – Jimmy Hoffa
    Feb 14, 2014 at 20:20
  • Immutability and side effect free is also a goal.
    – Martijn Verburg
    Feb 15, 2014 at 13:16
6

Josh Bloch's Builder pattern, much like the GoF Builder Pattern, offers a way of creating an immutable object with lots of default data without long lists of chained constructors.

If you "have the one constructor with required parameters, normal getters/setters" then your object is no longer immutable. ie. You can change it long after instantiating it.

If that's not a problem for you then you never needed the Builder pattern in the first place. If it is a problem then your solution is flawed.

Improve this answer
2
  • I don't think the builder pattern has anything to do with mutability, even the gof example on wiki is mutable ... en.wikipedia.org/wiki/Builder_pattern#Java also, the pattern has benefits that I outlined in the question.
    – NimChimpsky
    Nov 5, 2011 at 14:00
  • 3
    @NimChimpsky: Whether the Builder pattern can be applied to create a mutable object is not at issue. The question is, should you? Getters and setters have been around for eternity, where objects can be mutable they are a perfectly solid solution, but people ran into a common problem with creating immutable objects: unmanageable chains of constructors. The Builder was a common solution and thus became a pattern, to ease communication.
    – pdr
    Nov 5, 2011 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.