Is it common to have a constructor with 7 elements for example? or is it better to use many setters instead?
13
-
2Depends on whether or not you want a completely finished object when you're done providing the elements. If you hand all of the requirements to the constructor, you will have that.– Robert HarveyCommented Sep 23, 2014 at 22:25
-
1@RobertHarvey You seemed to be suggesting that there were reasons to want a not-completely-finished object and I was wondering what they were :)– Benjamin HodgsonCommented Sep 23, 2014 at 22:35
-
1@BenjaminHodgson: It's a veiled swipe at those folks on the SO question who think you can cleverly do it with a fluent interface (while accidentally forgetting one of the method calls). Let's see... how do you validate the object again?– Robert HarveyCommented Sep 23, 2014 at 22:39
-
1Why was this marked duplicate? The question referred to talks about functions more generally. I would argue constructors are a sufficiently special subset to warrant a new question. Notably: suppose it's a duplicate - I would have been quite unlikely to find the "duplicate" answer while searching for my question.– J TranaCommented Sep 24, 2014 at 2:56
-
1@JTrana MichaelK's answer could be pasted in here almost verbatim, and I'd up vote it as the correct answer here. All the points it makes are correct for this one. Thus, it highly indicates that it is a dup. If it isn't, then your observation that it is often a religious debate may push it in the direction of primarily opinion. As it is, this dup provides the path to the answer for the next person. I don't want to see what is in the SO answer here.– user40980Commented Sep 24, 2014 at 3:22
|
Show 8 more comments
1 Answer
First, I want to point out the excellent back and forth in the comments that shows the issue is nuanced - and often a religious debate.
There are many Java-specific comments about different frameworks, etc. - but I think the real meat of a question like this should stand alone from a specific framework choice and possibly even language.
I think the question you didn't ask was: "Does my object need seven others to work properly?" This may be a design smell - or it might be completely normal at a high-level tier of your complex program. This is the question I would ask first - any weirdness about the number of inputs doesn't change depending on the method of object creation.
Once it's known that all these objects as inputs do make sense, then it comes down to how the object is created. To @Robert Harvey's point, it's important to have a fully-baked object, or else you have to check if the object is good before you do any work anywhere in the object. I have seen that type of code and it tends to be less maintainable - I feel I can say that objectively. All arguments coming in on constructors is a nice clean way to do this, but if your inversion of control framework does it via private properties - does it matter? Protection exists in both cases.
-
I can design it anyway I want, the class simply is the git Commit which will have elements: author, message, sha, date plus 3 extra fields that we add for the commit– nemoCommented Sep 24, 2014 at 2:11