In such a case, with only a constructor like that one above, the client would need to pass null for the middle name String and zeroes or some other number without meaning.
In other words, suppose that all attributes of the class are optional except for the three just mentioned. Suppose that business logic is such that an employee should be instantiable with only a last name, first name, and ID provided. It is all too easy for a client to mix up the order of these same-typed parameters in the invocation. This particular constructor is particularly tricky for clients because it has three consecutive String parameters and numerous consecutive int parameters. * Edition of Joshua Bloch's Effective Java.Įmployee's parameterized constructor includes numerous parameters and this presents a challenge to clients of this class that need to create a new instance of it. * constructor to use Builder pattern as discussed in Item #2 of the Second * Simple employee class intended to illustrate NetBeans 7.2 and refactoring
To help illustrate, I include a code listing below. In this post, I look at the approach described in that chapter and look at how NetBeans 7.2 provides refactoring support for this approach.Īs outlined in Item #2 of the Second Edition of Effective Java, there are several disadvantages to using constructors with large parameter lists. This item addressed many issues I had run into during my Java development in a nice fashion. In particular, the usefulness of the first new item in the Second Edition (Item #2 "Consider a builder when faced with many constructor parameters") struck me. It did not take me long to realize that the Second Edition was worth purchasing. Shortly after the Second Edition of Josh Bloch's Effective Java was released, I borrowed a colleague's copy to browse it and consider purchasing a copy of my own despite already owning a copy of the first edition.