EDIT: Code Tags - JD
1) With an instance initialization block
2) With a constructor
These code blocks are missing a main method and need a method extraction for the printing method BUT writing them helped me think about instance method vs. constructor. Basically, using a constructor gives me more control over how I assign what is being passed into my object. The instance initialization block allows me to use values in an object. The constructor allows an object to inherit values when it is created. The difference is in how the values are passed in. Are they passed in when the object is created from an outside source (constructor) or do they already exist within the class (instance)? For more information, I found this article online: http://www.thejavageek.com/2013/07/21/initialization-blocks-constructors-and-their-order-of-execution/
I would hope you don't use an initialiser nor a constructor to print output to the screen. You might use print statements for debugging but printing output usually belongs inside methods rather than initialisers.
John Pacuta wrote:. . . how I would do that using an instance initialization block and with a constructor and then explain the difference. . . .
Thank you so much for your replies. I could sense that code had smells but I posted it to contribute. The truth is I don't really understand the concept and difference between instance initializers and constructors and when and where to use them. That information about class level statements not encapsulated in a method, haha I should know that! Is it wrong to post crumby code?
In my opinion, and on one hand, both constructors and instance initializers are used for initialization of the object -- and having more than one way to do it can lead to confusion.
However, on the other hand, perhaps you want the initialization code nearer (source location) to the declaration of the instance variable. And this may be hard to do with constructors, especially if you have many constructors. Also, instance initializers are always executed when an instance is created. With constructors, it may (or may not) be executed, depending on what constructors are called.
Naughty and mischievous trick:- Mark every instance field final. Compile the class. Ignore the compiler errors about field XYZ is final cannot be reassigned. Look for might not have been initialised compiler errors. If any such errors appear for your instance fields, then there is a path through a constructor which does not initialise that field. Then you know to correct that error. Once you have got rid of every might not be initialised error, you can take the final markers off again
When a class object is instantiated, first the VM allocates memory to hold the class resources - both the visible ones, such as instance variables, and the invisible ones (general overhead) and the inherited ones. At that point they are all blank. Then the methods of its superclass are invoked, initializing the inherited items. Then the "_init()" method is invoked, performing the statement and block init code. Then the explicit constructor is invoked, which in turn may invoke other super or local constructors (in that order).
A lot of times, I'll code an explicit method named "init()" that the constructor(s) can invoke. This is handy in cases where there's common code but nothing that one constructor can invoke from another constructor. And it's also very useful for re-usable objects, because I can recycle them by invoking init() without actually having to construct a whole whole instance (which I might not be able to link into existing operations).
Whether I code initialization statements or do it in explicit methods (constructor and/or init()) depends a lot on usage. Sometimes I want no ambiguity about an item's initial value - keeping the value and type definition visibly paired, so I'll code a direct assignment. Other times, the initial value may depend on context and/or I might want to re-init() it. Init blocks I do less often, and it's usually something I do when a simple statement isn't enough to initialize a value. For example, if I need to locate an external service first.
What is the point to them? If you are going to initialise a field to a default value every time, it is possible to do that in the constructor, or with a declaration‑and‑initialisation combined. There are also possible problems about order of execution with initialisers, which I read about in Java Puzzlers by Bloch and Gafter, but I have forgotten the details.
Mike. J. Thompson wrote:. . . Out of interest, why don't you like instance initializer blocks Campbell?
Now, static initialisers have the same risks about execution order if they are multiple, but if you only have one static initialiser which runs when the class is loaded (therefore before any constructors), then that is perfectly all right and if initialisation is complicated, probably the best way to initialise a static field.
You can try following:
1-Put the code separetly in all constructors
2-Put it into a method or any constructor then you can invoke them in every other constructor
3-Put it into instance initializer,all the codes get placed in the constructor automatically,which creates the instance of class
Sachin Tripathi wrote:1-Put the code separetly in all constructors
I don’t agree with this because of DRY (don’t repeat yourself). Code duplication can cause maintenance problems.
Sachin Tripathi wrote:2-Put it into a method...
I agree with this but the method must be final because according to Bloch, calling overridable methods during instance initialization can cause problems.