Is it better to have constructors with or without parameters?

Question

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
}

Answer 1

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.

Answer 2

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.

Answer 3

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.