First of all, thank you to everybody who answered that one. I appreciate your comments.
No need for an empty default constructor (at least 80% of code)
Although some specifications require a default constructor (JavaBeans, EJB 3.0, etc.) one can go with the one created by the Java compiler. The compiler does this if no other constructor is defined. Initialisation will always take place (comments from Peter Veentjer, Frank Nimphius, Sivakiran Kolli, Joern Horstmann).Good reasons for an empty default constructor (up to 20% of code)
- To enforce that your class is non-instantiable (see Effective Java Item 2 & 3) (comments from Brian Duff, Angus Myles)
- To ensure constructor chaining to the superclass. (comment from Angus Myles)
- To have a default way for construction while other constructors are more specific (comment from Robbie Vanbrabant, Sanjay)
Personally, I don't think that always defining a default constructor is a good idea. I came across many situations where I was happy not to have a default constructor (Kevin Smeyers, sorry for objecting).
Comments (5)
I'm surprised nobody mentioned this one: You should use a default constructor for documentation purposes, as not all default constructors are meant to be instantiated by the application developer. For example, you should add a javadoc to a default constructor saying it's meant to be used by hibernate, by x container, by the framework itself, etc. In this way you minimize the risk of the developer constructing a class they are not supposed to. If all of your classes are meant to be instantiated by an application developer, then less is to be gained - in regards to documentation - by adding the default constructor.
Posted by Shane Isbell | June 1, 2007 10:32 AM
Posted on June 1, 2007 10:32
I think that ensuring constructor chaining is only a valid reason under certain conditions.
If you only use the default constructor in the superclass for inheritance, by which I mean that it does not make any sense for the superclass itself, then I would make sure that the class will only be used for inheritance and not standalone. Declare it to be abstract, have protected or default access constructors and methods, and document the fact that it should only be used for that reason.
Also, all technical obligations aside, I think it's a matter of taste. My general rules:
- If the class uses it, and it's likely that you will add more constructors in the future, define it. AKA avoiding the "where did my constructor go?" build failure.
- If there are any technical obligations that don't conflict with the usage patterns you had in mind (see chaining above), define it.
Posted by Robbie Vanbrabant | June 4, 2007 3:21 AM
Posted on June 4, 2007 03:21
Am I wrong or is it when you add a constructor with non-empty parameter list that the default constructor (with empty parameter list) must be declared explicitely to be available?
Posted by Klaus Meffert | June 5, 2007 7:31 AM
Posted on June 5, 2007 07:31
My opinion was a little misunderstood I think. But no harm done.
I personnaly believe that you should think of your colleagues as your best friends. Be as clear as possible and avoid the (like Robbie mentioned) "where did my constructor go?" and "super()-call-failures"... So actually I like the fact that some IDE's automatically generate a public non-arg constructor for you. Since most of the time, I don't have to delete it.
krgds,
Kevin
Posted by Kevin Smeyers | June 7, 2007 8:36 AM
Posted on June 7, 2007 08:36
Hello! Good Site! Thanks you! vpfjgxovdnvcw
Posted by kwbiiwllim | August 19, 2007 4:36 PM
Posted on August 19, 2007 16:36