I think it's generally best to instantiate an object when it's declared (if possible). That way, you guard against a NullPointerException.
For example, if you say...
...then the object is ready for any code that might try to use it. On the other hand, if you say...
...then if any code other than that method tries to use it, there could be a problem. (And the fact that it's declared outside of the method suggests that's a possibility.) [ August 15, 2007: Message edited by: marc weber ]
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
posted 11 years ago
So is there any reason to do it one way or the other?
I prefer the second one. In that way you create an object when it's necessary. With the first way you could instantiate elements that would not be used in you programm.
The constraint with the second way is that you have to be carefull NullPointerException. You have to check that the variable is istantiated before using it. [ August 15, 2007: Message edited by: Collins Mbianda ]
However it is probably much more common (not to mention clearer to those reading the code) to have instance variables initialized in a constructor than a method. If the variable is only used in a single method, it should be local to that method. If it is used by more than one method, then it should be initialized when it is declared as in the OP's first example, or initialized in a constructor.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Any field that can be declared "final" should be declared "final".
To be declared final, an instance (i.e. non-static) field's value must be available when the object is constructed and must not need to change after that. You can assign the final value in the declaration, or in constructor(s).
The reasons that "final" is desirable include: -
prevents run-time bugs where you inadvertently change the value of a field that shouldn't change. If you try this with a "final" field, you get a compile-time error, which is easy to spot and to fix.
may enable the Java compiler, or the HotSpot JIT compiler, to optimise your code to run faster. If it knows the value won't change, more optimisations are available.
eliminates the need to synchronise access to the field from multiple threads
[ August 16, 2007: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
I think too, Ryan, that it is good to look at it as just two techniques for use under different circumstances.
Sometimes, you are in code that is doing initialization, you are declaring the reference variables, and you know what objects need to be instantiated. In that case the one liner makes sense.
In another case, you might be in a method that has been passed an object reference of some kind and, in that object, is a reference variable already declared. You might need to instantiate some new object and assign it to that variable. The second one fits that bill, except that you would not be the one actually declaring the reference, just assigning to it.
SCJP - 86% - June 11, 2009