拥有90％静态成员的Java类。 好的做法还是什么？

Question

I'm 14 and have been learning java for about 4/5 months. I'm coding a game now called super mario winshine and i wanted to know if it is good practice to have a class that is mostly static variables.

The class is the one that holds all the information for the game's level/world. Since I only need one version of this class, and lots of other classes will be using it, I choose to make all the variables static. Is this good practice?

I have considered the fact that i could keep the variables "non-static" and just clone the main object i use for that class, but I thought i would rather sacrifice "OO" for memory in this case.

Answer 1

As soon as you want to have two or more worlds this will fail. Say, when your first release is a runaway success and you want to add the "parallel universe" expansion set.

In my experience, 90% of the time when marketing says "oh, don't worry, there will only be one Application/Window/Database/User" they are wrong.

ADDED

I would also avoid using a true Singleton pattern with World.getInstance() etc. Those are for the rare cases where it really is an essential requirement that there only be one of something. In your case, you are using it as a convenience, not a requirement.

There is no perfect fix, YMMV, but I'd consider a single static method, something like

   World World.getWorld(String name)

and then you call real (non-static) methods on the World that is returned. For V1 of your program, allow null to mean "the default world".

Some might put that method into a class named WorldManager, or, perhaps showing my age, a more clever name like Amber. :-)

Answer 2

It all depends upon what your methods and classes are. There is no problem in defining utility methods as static methods in a class. There is no need to make it a singleton as others are suggesting. Look at the Math class from java.lang package. It has lot of utility methods but it isn't a singleton.

Also check out static imports functionality. Using this you doesn't need to qualify method calls with the class name.

Answer 3

Well, what you are doing is definitely an option. Or you could use a singleton pattern:

public class World {
   private static World instance = new World();

   private World() {
   }

   public static World getInstance() {
       return instance;
   }
}

Now just use World.getInstance() everywhere to have a unique object of this type per application.

Answer 4

I would say it's definitely not a good practice.

I've not seen your code, but having several static variables in a class that other classes access freely seems to indicate that you're not really using object orientation/classes but more just writing procedural code in Java. Classes should generally encapsulate/hide all their variables - static or not - from access from other classes so that other classes don't depend on how the class is implemented.

The static part also causes problems with making threads work (global variables are hard to lock in a good way so that nothing deadlocks) and with unit testing (mocking is all but impossible)

I also agree with the other posters, if you need "global variables", at least make them singletons. That allows you to change strategy easier later and does not lock you to one world.

Edit: I'm definitely not advocating singletons as a good pattern here if someone read it like that, but it does solve some problems with static variables, esp. regarding testing/mocking compared to just statics so I'd say it's a ever so slightly lighter shade of gray :) It is also a pattern that is easier to gradually replace with better patterns by for example using a IoC container.

Answer 5

You may wish to look into implementing this class as a singleton , while there is nothing particularly wrong with your approach it may lead to some inflexibility further down the road.

Also you should take in to consideration the purpose of static members which is to be a member of the class and 'act' on/with the class not an instance of it. For example the static method in a singleton returns either a new instance of the class if one doesn't already exist or returns the instance, and because the method is static you do not instantiate a new one. This is probably worth a read because it can be somewhat confusing when determining the appropriate use of static members

Answer 6

I think it is fine as long as you don't need anything more sophisticated, in other words, static fields are OK as long as different objects (including subclasses if there will be any) do not need different values.

You code by yourself, refactoring is easy with modern tools, me says don't fix it until it is broken, and focus on the algorithmic aspects of your project.

Perhaps you may think to encapsulate all those static fields within a different static class, as it is a good principle to "keep what changes seperate from what does not". Chances are one day you will want to initiate that static class with different values, for example want to read the initial values from an XML file and/or registry, add behaviour, etc. so instead of a static class you will implement it with a Singleton pattern.

But clearly that is not the concern of today. Till then, enjoy!

Answer 7

I'm not sure what you are really talking about from your short description, so I'll try this:

public class Level {
  static List<Mushroom> mushrooms;
  static List<Coin> coins;
  ...
}

Is that you were describing?

You asked if this is "good practice" and I can tell you that this looks very odd, so, no, it's not.

You gain absolutely nothing by doing this. You make it impossible to have more than one Level , which brings no advantage, but it could cause trouble in the future.

I didn't understand your last paragraph where you say you made most things static to save memory. You would usually create one Level and it would be passed around (without cloning) to the various classes/methods that read from it or modify it.