Is there a reason to explicitly code a default constructor when there are no other constructors?

I recently saw this constructor in a class:

public MyClass(){ }

There were no other constructors.

Is there a reason for this? Java automatically creates a default constructor, so why would you declare on开发者_如何学编程e explicitly? Or is this considered good practice in the same way as using braces for single-statement if statements - in case other constructors are added later and you forget that you don't have a default...?

A couple minor points that aren't likely to be why you saw it in this case.

• It gives you something to set a breakpoint on.
• You could make it non-public

As far as "in case other constructors are added later and you forget that you don't have a default" - that might be a reason, I suppose. But if a non-default constructor were added, any code that used the default constructor would fail to compile, so the guy adding the new constrcutor would generally need to also add a defintion for the default ctor as well.

Then again, I can't think of any particular harm in having the empty ctor defined (though now that I've typed that, I get a feeling that someone might point out some corner of C++ where it could bite you).

It doesn't play any role and can safely be deleted.

Here is what Java Language Specification says:

If a class contains no constructor declarations, then a default constructor that takes no parameters is automatically provided:

• If the class being declared is the primordial class Object, then the default constructor has an empty body.
• Otherwise, the default constructor takes no parameters and simply invokes the superclass constructor with no arguments.

So default constructor will be created anyway. There is no sense to write it if you don't. have to.

IMO you should only do it if you want to change the visibility level of your constructor, i.e. make it private or package protected

Although nothing is gained by adding the constructor explicitly at the technical level, there are potentially reasons to do it. One would be if the class is instantiated via reflection, you may want to put some documentation on the default constructor to indicate that it is required even though adding a new constructor would not cause a compilation error.

Another is that some coding standards prefer it in order to explicitly indicate you thought about what kind of constructor this class is supposed to have.

Because you believe in the second sentence of the zen of python :

Explicit is better than implicit.

Correct me if I'm wrong (I haven't done Java in a while), but doesn't this prevent a call to the parent constructor? In which case the reasoning is obviously that the parent is going to do something automatically that you don't want to happen in this class.

I was taught that a public default constructor was required by the java bean specification.. The wikipedia page http://en.wikipedia.org/wiki/Java_Bean also lists it as a requirement.

On the other hand, I looked at the Sun/Oracle site and couldn't find mention of it. See http://java.sun.com/developer/onlineTraining/Beans/Beans1/simple-definition.html

There is actually a good reason to include it not mentioned in these answers:

If the existence of a no-argument constructor is explicitly part of the contract for your object, then it should be explicitly stated.

If you explicitly intend for the client to subclass your code, as in e.g. Java Swing, then its a good idea to explicitly make an accessible no-arg constructor, even if there are no other constructors. Otherwise, if another programmer, in their wisdom, decides to make another constructor, the new explicit constructor will remove the implicit no-arg constructor and break the client code.

If the code is sub classed in your own code base then this will show up as a compiler error, but if your code is to be published as a jar, and sub-classed by the client there will be no compiler error.

Of course, you could argue that if its part of your contract you should have a junit test for that, and you would be right! But if you are working on a large code base where tests take hours to run for your daily build, breaking your daily build because you forgot you had to explicitly make a no arg constructor when adding a constructor is a huge time waste when an explicit constructor and a comment would have avoided any chance of an error.

The goal of good code is to make it as easy as possible for another developer to change it without a mistake!