MarioDS
MarioDS

Reputation: 13063

final variable assignment: at declaration or in constructor?

First of all this is NOT an exact duplicate of Initialize final variable before constructor in Java. It is probably related, but there aren't any answers that satisfy me.

My problem is about final variables in Swing GUI's. It's about custom Actions in particular. I have a number of final variables and a number of static final variables.

The question is: if the variable is actually a constant, what is better: initialise them at construction-time, or initialise them at declaration?

The answers on the question I mentionned above generally point towards making the variable static as soon as you are able to assign it when you declare it. That doesn't really make sense to me, as the variables aren't used in a static context. I have a couple of Images that my form uses like icons, I made those static because an Image simply is a static thing unless your application modifies them. That makes sense.

On the other hand, the Actions are new instances of a custom inner class. Very technically they are static too, but it just feels different. They simply mustn't be available in static context imo. So do I put:

private final CustomAction customAction = new CustomAction();

Or do I initialise it in the constructor? Which is better? Or am I thinking the wrong way about static?

Upvotes: 4

Views: 4825

Answers (4)

CodeBlind
CodeBlind

Reputation: 4569

I think you're on the right track with not making it static, because it sounds like your CustomAction objects are truly custom to the instance of the GUI that creates them in its constructor. I think whether you initialize it in the constructor or not depends on whether your constructor could initialize a CustomAction differently based on the constructor's input arguments.

Where static versus non-static is concerned... a good rule of thumb is, if a variable is going to remain constant across all instances of a particular object type, then that variable should be static. This saves memory over the runtime of your program and also saves CPU time when each object instance is constructed, since that constant won't have to be initialized every time you create a new instance of your Object. On the other hand, if a variable is going to remain constant for a particular instance of an Object, but may be different from instance to instance, then it shouldn't be static.

Finally (pun intended), final should be used whenever you don't want a primitive value or reference to an Object to ever change. The static or non-static context doesn't really influence whether a variable should be final, it's strictly final because the developer doesn't ever want to change that variable. Its static context depends solely on how the developer wants it to be accessed.

Upvotes: 1

Joop Eggen
Joop Eggen

Reputation: 109547

For a fast application startup and program parts the user possibly does not visit (About dialog), static is not good. In general static is not very liked as you did find out. There are some reasons, but nothing very convincing. But sometimes it is a anti-pattern or a sign of it.

Still in your case I would refrain from static images. By the way resources are cached internally.

Upvotes: 0

bpgergo
bpgergo

Reputation: 16037

Initialize your constant variables at declaration: it is more readable. Make it static if it does not make any sense to put different values into it for different instances of the class, that is, if it is a class level variable, not an instance level.

Upvotes: 1

mre
mre

Reputation: 44240

If the field is a constant, make it a static final member of the class,

public class Foo{
    public static final int BAR = ...;
}

Otherwise, initialize the field in the constructor.

Upvotes: 5

Related Questions