I’m not so advanced in my programming skills. That’s why i ask if Nifty Gui Should be static or not? Especially if i will use many AppStates and Threads.
I’m talking about this:
[java]
private static Nifty nifty;
…
public static Nifty getNifty() {
return nifty;
}
[/java]
I saw some examples with static nifty and some examples without static.
Generally static accessors should only be for system-wide things or for boilerplate code in self-contained methods. In libraries you should avoid them altogether as you cannot know how many instances of the library the user needs.
So its your decision. Are you 100% positive you will ever only need one of these on one computer?
@normen said:
Generally static accessors should only be for system-wide things or for boilerplate code in self-contained methods. In libraries you should avoid them altogether as you cannot know how many instances of the library the user needs.
So its your decision. Are you 100% positive you will ever only need one of these on one computer?
My client game has GuiManager which has only one nifty object. This nifty can be get by different classes. i get access to the nifty through stateManager.getState(GuiManager.class).getNifty().
But i think for future development it’s better to live the nifty dynamic. As in future i will possibly split gui code into different parts. Thanks!
Hm… well, static variables do have their liabilities, too. For example, classes may be loaded (and statics initialized) earlier than you expected (common cause: the seemingly-innocent instanceof check), causing all kinds of bugs because the initialization assumes the presend of things that aren’t available yet. Object creation is easier to sequence.
So I used a member variable in my AppState subclass. The initialization code still had sequencing bugs, but at least these were easy to fix.
The thing I regularly set up and shut down were Screen objects.
@toolforger said:
Hm... well, static variables do have their liabilities, too. For example, classes may be loaded (and statics initialized) earlier than you expected (common cause: the seemingly-innocent instanceof check), causing all kinds of bugs because the initialization assumes the presend of things that aren't available yet. Object creation is easier to sequence.
So I used a member variable in my AppState subclass. The initialization code still had sequencing bugs, but at least these were easy to fix.
The thing I regularly set up and shut down were Screen objects.
I think the question isn’t static vs. nonstatic, it’s whether you need a Nifty object
per-JVM (static)?
per Application? (Application member)
per Spring context? (Container-configured bean)
per something else? (member of that something else)
We’d need to know your future plans for your application to answer which trade-offs are relevant or not to you; I guess you’re in a better position to judge that than us
Bottom line, though:
If you can find an easy way to get the behavior that you want without using a static reference then it is always better. Sometimes this is only a small design tweak.
To use static or not is only a valid question when easy ways to avoid it have been exhausted.
Edit: and often these small design tweaks have other positive aspects.