1/05/2007

Always write a no-arg constructor in a java class

When a java class contains no constructor, the compiler will generate a default no-arg constructor. But it's always a good idea to explicitly write this no-arg constructor. Some good reasons:

1. To future-proof this class and all its subclasses.

Constructors in all subclasses always calls the superclass' constructor at the first line, explicitly or implicitly. If the superclass does not define any explicit constructor, a default no-arg constructor is called. Therefore, subclasses rely on the fact that a no-arg constructor exists in the superclass. Otherwise, they will fail to compile.

However, the default no-arg constructor will not be generated by javac when the class defines any constructor. So it's likely that when a parametered constructor is added to superclass in the future, the no-arg constructor cease to exist, which will cause subclasses to fail to compile.

2. To future-proof conformance to certain Java standards.

In many Java standards or specifications, components are required to have a no-arg constructor. For example, JavaBeans, EJB, Servlet, JPA, etc, because these component classes are instantiated and managed by their respective containers. For the same reason as above, a default no-arg constructor may exist now by disappear in the future. By defining a no-arg constructor, your code is more maintainable and robust.

3. It's easy. Most IDEs like Eclipse or NetBeans can generate it for you.

4. Control its access modifier, making it private or protected, rather than public.

The generated no-arg constructor is always public, which may not be the best. For example, for utility classes that only contains static methods, clients never need to instantiate instances. Or for singleton, you also want to prevent external instantiation. Therefore, a private (in some rare cases, protected) no-arg constructor is more appropriate.

2 comments:

Ricky Clarkson said...

It's not a good idea to write the no-arg constructor, unless you need it.

"1. To future-proof this class and all its subclasses."

I'd rather prevent subclassing. Without preventing subclassing, you may want your 'real' constructor to be called rather than the no-arg constructor, to ensure that fields are set properly.

Failing to compile is better than compiling but failing to work.

"2. To future-proof conformance to certain Java standards."

You Aren't Gonna Need It. You can always add the no-arg constructor if it's required; don't just do something because you might possibly need it one day. Do it when you know you'll need it.

"3. It's easy. Most IDEs like Eclipse or NetBeans can generate it for you."

That only supports the idea of doing it when you need it. If it was hard to do, then arguably you should do it before you need it (it might be cheaper to do it now than later).

"4. Control its access modifier, making it private or protected, rather than public."

That just restricts the number of programmers who can use it; it's better to prevent even the writer of the class from calling a constructor if it's not intended to be used.

"The generated no-arg constructor is always public, which may not be the best."

Technically untrue, though the difference is unimportant. A package-private class' default constructor is package-private.

In short, don't write code that you don't need.

Steve Smith said...

Great and Useful Article.

Online Java Training

Java Online Training India

Java Online Course

Java EE course

Java EE training

Best Recommended books for Spring framework

Java Interview Questions








Java Course in Chennai

Java Online Training India