-1

Is it common to have a constructor with 7 elements for example? or is it better to use many setters instead?

nemo
  • 115
  • StackOverflow: How many constructor arguments is too many? –  Sep 23 '14 at 22:20
  • 2
    Depends 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 Harvey Sep 23 '14 at 22:25
  • @RobertHarvey I can't think of many good cases where you wouldn't want a completely valid object from the constructor (except when it's impossible, such as certain types of circular dependency) – Benjamin Hodgson Sep 23 '14 at 22:32
  • @BenjaminHodgson: Yes, that's what I said. – Robert Harvey Sep 23 '14 at 22:34
  • 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 Hodgson Sep 23 '14 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 Harvey Sep 23 '14 at 22:39
  • This is a long-time religious argument. e.g.: The Spring framework originally only supported objects with a default constructor, and injected properties through setters. But that didn't go over well, so they also added support for injecting properties through constructor arguments. These days, the constructor guys are a little more feverish about the whole thing (see comments above), so they seem to be winning. But in practice, there are a variety of options -- including a default constructor with private, annotated properties. – sea-rob Sep 23 '14 at 23:18
  • For object construction that is complex, an object has many final fields, etc. I recommend the builder pattern. Hide the complexity, and throw an exception if the object cannot be properly constructed. –  Sep 23 '14 at 23:19
  • And of course @RobY gives the counterexample, beans that require default construction. Then again, the question was not specific about the context in which objects are constructed and if IoC compatibility, reflection construction, etc. are relevant. –  Sep 23 '14 at 23:21
  • @RobertHarvey Not sure what you mean. The fluent builder can be in a state where calling build() will throw an exception, but once you get a successful object back from the builder, you know it's completely valid because it used the constructor. I don't see any advantage to using it just because you have "too many parameters", but if you have too many possible combinations of included/excluded parameters, then I could maybe see it being handy. – Ben Aaronson Sep 24 '14 at 01:30
  • 1
    Why 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 Trana Sep 24 '14 at 02: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. –  Sep 24 '14 at 03:22
  • Fair enough. I think MichaelK's answer gets a good ways there - it addresses the number of arguments and the potential design smell there. That's sort of the meta-question. I don't think it hits @RobertHarvey's point about the object being valid, as that is unique to the constructors vs. setters part of the question. But I definitely agree that SO answer is not what we want to propagate here. Thanks for taking the time to explain! – J Trana Sep 24 '14 at 05:27

1 Answers1

2

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.

J Trana
  • 1,369
  • 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 – nemo Sep 24 '14 at 02:11