Lately, I have been advised on using Builders instead of constructors when creating an object. I didn't know what builders back then were but have been reading on them and I believe I have a fairly pretty good idea of what builders are and how to use them. However, isn't it waste of code if I am only going to have one constructor even if I will have in that constructor over 4 fields to be filled??
I'll tell you what is wasted most when you have a parameter list that has more than three or four items: Time. A lot of time has been wasted from debugging problems that come with long parameter lists. A lot of time wasted from trying to figure out what something like this might mean:
Can you tell me which parameter is the first name? Are you sure?
Which parameter is the penalty for overdrafts? Which is the initial deposit? Which one says that online statements are enabled? Which one says that this is a co-owned account? Sure, you can go to the underlying code and maybe match up each parameter to the constructor's signature but again, doesn't that waste time? Compare that to this:
Isn't that much clearer?
Debugging and Maintenance TIME is the most costly part of software development. Save that instead of "code".
Practice only makes habit, only perfect practice makes perfect.—every music teacher ever
Practice mindfully by doing the right things and doing things right.— Junilu
What I was taught was it is okay to have three to five parameters for constructors, which I'm pretty sure I read in OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808 by Jeanne Boyarsky and Scott Selikoff, however I'm not 100% sure about that at the moment.
If you have more then a reasonable amount of parameters then you may want to look into the builder pattern as you have stated.
However you need to draw a line in the sand somewhere and you need to know when it's okay to go past that line.
If the value of a field can be directly inferred or calculated or a reasonable default used then maybe you don't need to have that many fields in your constructor.
I'm not too sure that there are hard rules as to how many parameters a method or constructor should have. But the more that you have the harder it can be to keep track of when creating that object or using that method.
The other serious problem which were not mentioned yet may come into picture are telescoping constructors. Joshua Bloch in his famous book Effective Java spends 6 pages explaining that (Item 2).
When there are many parameters, usually there are also cases when object initialization doesn't require them all from the client side, so you need to overload constructors by supplying to an overloaded constructor the "default" values, so you still have object in a consistent state:
Pete Letkeman wrote:What I was taught was it is okay to have three to five parameters for constructors
That probably would sound okay to have one to three and in an exceptional cases maybe, maybe five, but that supposed to be under serious suspicion.
In some cases you may find, that if you have 5 or so parameters, you don't even need a builder, because some of those parameters nicely form a class themselves, i.e.:
could be replaced with:
So, always need to think and assess particular case. In most of the cases probably the good programming guidelines would appear to be right, and only a smaller portion of corner cases would prove to be acceptible as fine.
And what about this sort of code?If you really h ave that many parameters, how many constructor overloadings are you going to need to fit them all in? Will you need 2ⁿ constructors, where n is the maximum number of parameters?
Campbell Ritchie wrote:If you really h ave that many parameters, how many constructor overloadings are you going to need to fit them all in? Will you need 2ⁿ constructors, where n is the maximum number of parameters?
You are right, problems might become way more serious than one could think.
posted 1 year ago
Last night, I wrote:And what about this sort of code? . . .
There is something wrong with it; how many people noticed that? Editing the code to obviate long lines made it harder to spot the problem, I think.