Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Instantiation levels?  RSS feed

 
Ryan Waggoner
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure if that is what you call it but my question was about this...


VS


I am not quite sure what the big difference is here, can someone help me out?

Thanks.
[ August 15, 2007: Message edited by: Ryan Waggoner ]
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ryan Waggoner
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So is there any reason to do it one way or the other?
 
Collins Mbianda
Ranch Hand
Posts: 262
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ryan Waggoner:
So is there any reason to do it one way or the other?

There are different things to consider. See this thread.
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ryan Waggoner:
So is there any reason to do it one way or the other?


The first way cannot be used all the time. Frequently your member objects get passed data to use in their initialization.

 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One more thing on a related note.

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 ]
     
    Bob Ruth
    Ranch Hand
    Posts: 320
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Ryan Waggoner
    Ranch Hand
    Posts: 75
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks a lot for the help everyone.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!