Hi guys!
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.
Thank you.
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!
Is Nifty even able to manage more than one Nifty object?
I was under the impression it cannot.
@toolforger said: Is Nifty even able to manage more than one Nifty object? I was under the impression it cannot.
So, it’s better to make it static?
Technically you can create new NiftyDisplay and get the new Nifty.
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
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.
Are you allowing the client to be run more than once on a single machine?
EDIT: I usually only use static for defining data that is non-class specific and should be accessible globally --OR-- utility classes/methods.
Not saying these are the only uses, but 99% of time, this ends up being the case.
Thank you all. It seems i understant this topic. I’ll leave it nonStatic for a while. Anyway i can tweak it in future.
THANK YOU ALL!