5

Is it better to have constructors with or without parameters and why?

public NewClass( String a,  String b, int c) throws IOException
{
    //something
}

OR

public NewClass() 
{
    //something
}
|improve this question|||||
  • This stackoverflow.com/a/19759758/2776866 and this stackoverflow.com/a/19759553/2776866 prompted me to ask this. – user208372 Nov 4 '13 at 6:45
  • If this is too broad or off topic pls let me know. – user208372 Nov 4 '13 at 6:47
  • 5
    It's a design choice, it's more about what you need than which one is "better". Do you need to feed your object the parameters upon instantiation? If so, go with the first approach. If not, go with the second. – yannis Nov 4 '13 at 6:51
  • 1
    Do not deleted it, nothing wrong with simple questions (we were all new once). I don't have time right now to post a proper answer, but someone else probably will, soon. – yannis Nov 4 '13 at 7:03
  • 1
    The answer to stackoverflow.com/questions/2848938/… has really nice related info about building objects that have many "parameters". – Pieter B Nov 4 '13 at 8:53
21

A constructor should establish the initial invariant of your object, that is, put it in a valid and usable state.

If your object is not really usable as an instance of the type it is after construction, it's a sign that you've got a bit of a smear between initialization of the object and use of the object.

If it's impossible to provide all the information needed up-front to construct your object properly, you may want to consider some sort of builder to gather state incrementally before instantiating the object.

In general, zombie-type objects which have initialization after construction and invalidation before disposal tend to be error-prone, particularly if there is no language support for it, leaving you to enforce the concepts in documentation and assertions.

|improve this answer|||||
  • ty for this, it's what I suspected.. so it's good to be reassured I'm on the right track. I appreciate your time for a basic Q. All these basic Qs are going to add up to me writing good code, as I'm pedantic.. so cheers – user208372 Nov 4 '13 at 7:50
  • 2
    I've been bitten by incomplete constructor bugs many times, granted in C++ sometimes incomplete constructors are required because of the limitations of the language. In Java I find that the factory constructor technique can almost always eliminate incomplete constructors. – Michael Shopsin Nov 7 '13 at 16:58
0

You should favor parameterless constructors.

There's two main reasons for this, the first being that constructors have no good way to report errors. Sure, you can toss exceptions but that's a fairly high impact response to simple bad data - it forces the users of your object to treat it with undue care since any creation can throw.

The second is that it can sometimes (in some languages especially) cause disconnects (or duplicated code) between the validation for constructor setting and property setting to enforce your invariance. Since the class invariants are the same, the validation should be the same. By allowing two effective ways to set values, it complicates the class' validation.

To be clear, I'm not saying to never have parameterized constructors. And I'm definitely not saying to have some Initialization method. What I'm saying is that objects should have a clear, well-defined initial state with sane defaults.

Sometimes objects can't have sane defaults and instead need their initial state passed to them. It happens. But in general, you should look to avoid it.

|improve this answer|||||
  • 1
    What about dependency injection? – Wilbert Nov 4 '13 at 14:37
  • @Wilbert - what about it? There's a hojillion ways to do dependency injection and passing stuff into the constructor is only one. And even there, sane defaults are good. – Telastyn Nov 4 '13 at 14:38
  • 1
    the double validation issue isn't really one imo... if you really need those rule simply use the Property(ies) from the constructor and add validation in there – Rémi Nov 4 '13 at 19:59
  • @im_a_noob - not all languages support calling member methods/properties from the ctor. – Telastyn Nov 4 '13 at 20:19
  • @Telastyn true but many of them support this and in this case it's java so you can do this. – Rémi Nov 5 '13 at 12:14
0

I prefer constructors with parameters and there are two main reasons:

  • Passing values into a constructor means that the fields can be final and therefore validated and set one time only. Note that final fields make multi-threaded coding much simpler (see http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601).
  • Makes testing much easier if the values (especially objects) passed via a constructor can be mocked to behave in a desired way. Helps testing in isolation.

I don't think there is anything wrong with getter setters, but I typically only use them in a 'builder' or 'bean' class.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy