to static or not to static

Newbie & Debugging Questions
#1

ok, seen it done both ways and based on an example I went this route. Then kinda stuck with it. My main game class has the following code snippet:


        /** TextureLoader */
        public static TextureLoader textureLoader;
        
        /** Font Writer */
        public static FontWriter fw;
        
        /** SplashScreen */
        public static SplashScreen splash;
        
        /** Client - foer server communication */
        public static Client client;
        
        /** LoginManager - for login, player create steps */
        public static LoginManager loginManager;
        
        public static List<gl2DComponent> components = Collections.synchronizedList(new ArrayList<gl2DComponent>());

private static void run() {}


private static void render() {}

This objviously allows access to these object from just about anywhere. I know this isnt the most object oriented path(or maybe it is).
Would you do it another way?

#2

Well, it doesn’t hurt anything to use static AND final objects. If you want to allow assignments, then you should really use setters and getters. Of course, it doesn’t actually matter if no one else will ever use the code. OO design is really one of those “protect you from yourself” type of things.

A good comparison is database foreign keys. Sure, you can get away without using foreign keys, but wouldn’t you feel much safer if you knew for a fact that no one could add garbage ids?

#3

[quote]Would you do it another way?
[/quote]
Yep. Definitely.
Not that what you’ve done is “wrong”.
I’ve just found that if you get out of your static main() method and into an instance method as soon as possible, it makes it much easier to refactor stuff when the time comes.

Here’s my re-do of your code:


public class Game {
   /** TextureLoader */ 
   private TextureLoader textureLoader; 
    
   /** Font Writer */ 
   private FontWriter fw; 
    
   /** SplashScreen */ 
   private SplashScreen splash; 
    
   /** Client - foer server communication */ 
   private Client client; 
    
   /** LoginManager - for login, player create steps */ 
   private LoginManager loginManager; 
    
   private List<gl2DComponent> components = Collections.synchronizedList(new ArrayList<gl2DComponent>()); 

   private void Game() [
     // Initialise all the above stuff here!!!
   }
 
   private void run() {} 
 
   private void render() {} 

   public static void main(String[] argv) {
     new Game().run();
   }
#4

I have headed to the masters :slight_smile: …I have refactored 90% of my statics and now initialize by passing reference to parent.

thanks!

#5

I use statics all over the place :slight_smile:
So much easier. So much more sensible when you’re writing a standalone game!

Cas :slight_smile:

#6

If it was mutliplayer, would you switch to instances?

#7

Getter/setter or public static… it’s pretty much the same. Both means you lose a bit data encapsulation, both means those objects are now coupled together and you should try to avoid both of em were possible.

#8

nice. the topic static vs oop is a little like attacking the holy cow. i had (have?) this problems myself and discussed with many people about that. even my professors have very different opinions about that. old school programmers often tend towards the practical static.
it often gave me headaches cause clean oop can cause several headaches. sometimes it is necessary to take care of a big pattern only to avoid direct access.

now i use static much more than before, especially when i know that i really need only one instance. my server only needs one gui, my game only one resourcemanager. and those components often need to be accessed from the farest place of your class structure, often only one time in a year.

#9

No difference in multiplayer either.

Cas :slight_smile:

#10

Great! :slight_smile:

I think I have a happy medium that I am comfortable with. Now that base classes are done…I can extend till I am blue in the face and have access to whateva I need.

#11

reading this post made me think of many singleton classes that I’ve written for managing various resources etc. It seems to me like the very nature of a ‘singleton’ class makes it suitable for everything being static instead of the general implementation (stores a single instance of itself with a private constructor and a public getInstance() method). Wouldn’t it be better (or at least equivelant) to make all attributes and methods static? there is really no point in creating the object of the class if you know there will only be one instance of it ever. Any downside to doing this (other than OOD purists yelling at me)?

#12

although i am not doing this (making all static, if you dont need many instances) it should be a good way. especially when youre taking into mind that static variables are slightly
faster to access than member ones.

but on the other hand, when i look back at most of my projects there aren’t too many cases where you can declare lots of variables static. only few classes (often manager entities) only need to be instantiated once. or there is the problem that you need to harmonize the access from static to
member entities…

#13

[quote]there is really no point in creating the object of the class if you know there will only be one instance of it ever. Any downside to doing this (other than OOD purists yelling at me)?
[/quote]
Prepare to be yelled at >:( … just kidding.

I believe (IANAnExpert/Academic) the major benefit of using a Singleton (which is an object) rather than static methods is that if, in the future, you decide to provide an alternate implementation or an enhanced implementation of the methods, it would be very easy to change either the call that returns the singleton or the call that retrieves the singleton to return/retrieve a different object with the same interface (read “method signatures” not necessarily “java interface”). If using static methods, you would have to manually change EVERY call to those methods to make the same change.
So, in essence, it’s a future-proofing pattern, not one that gives any particular advantage at runtime.