A Java class that has 90% static members. Good practice or what?

Question

I am 14 years old and I have been studying java for about 4/5 months. I am 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.

A class is one that contains all the information for the game level / world. Since I only need one version of this class, and many other classes will use it, I want to make all variables static. Is this a good practice?

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

Answer 1

Once you want to have two or more worlds, it will not succeed. Say when your first release is rampant, and you want to add a parallel universe expansion kit.

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.

ADD

I would also avoid using a true Singleton template with World.getInstance (), etc. This applies to rare cases when it is really an important requirement that only one of them. In your case, you use it as a convenience, not a requirement.

There is no perfect fix, YMMV, but I would consider one static method, something like

World World.getWorld(String name) 

and then you call real (non-static) methods in the returned world. For V1 of your program, enable null to the default world.

Some may put this method in a class called WorldManager, or possibly indicating my age, a smarter name like Amber. :-)

Answer 2

It all depends on your methods and classes. There is no problem defining utility methods as static methods in a class. There is no need to make him single, as others suggest. Take a look at the Math class from the java.lang . It has many useful methods, but it is not a singleton.

Also check static imports . Using this, you do not need to qualify method calls with a class name.

Answer 3

Well, what are you doing, definitely an option. Or you can 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 for each application.

Answer 4

I would say that this is definitely not a good practice.

I have not seen your code, but with a few static variables in the class that other classes freely distribute, it seems to indicate that you are not actually using object / class orientation, but rather just writing procedural code in Java. Classes should, as a rule, encapsulate / hide all their variables - static or not - from access from other classes, so that other classes do not depend on how the class is implemented.

The static part also causes problems with creating threads (global variables are difficult to fix in a good way, so nothing happens) and with unit testing (bullying is almost impossible)

I also agree with other posters if you need "global variables", at least make them single. This allows you to change your strategy later and does not block you in one world.

Edit: I definitely do not advocate singles as a good example here if someone has read it this way, but it solves some problems with static variables, especially. in terms of testing / bullying compared to just statics, so I would say that it is ever slightly lighter shade of gray :) This is also a template that is easier to gradually replace with better templates, for example, using the IoC container.

Answer 5

You might want to study this class as a singleton , while there is nothing particularly bad in your approach, it can lead to some inflexibility down the road.

You should also take into account the purpose of the static members, which should be a member of the class and "act" in / with the class, not its instance. For example, the static method in singleton returns either a new instance of the class, if it does not already exist, or returns an instance, and since the method is static , you are not creating an instance of new . This is probably worth reading, because it can be somewhat confusing when deciding on the appropriate use of static members.

Answer 6

I think this is normal if you don't need anything more complicated, in other words, static fields are in order, until different objects (including subclasses, if any) need different values.

You yourself code, refactoring is simple using modern tools, I say that do not fix it until it breaks, and focus on the algorithmic aspects of your project.

Perhaps you might consider encapsulating all of these static fields in another static class, as this is a good principle: "keep what changes separately from what doesn't." Most likely, one day you will want to initiate this static class with different values, for example, you want to read the initial values ​​from an XML file and / or registry, add behavior, etc. Therefore, instead of a static class, you will implement it using Singleton .

But it’s clear that today is not a problem. Until then enjoy!

Answer 7

I'm not sure what you are really talking about in your short description, so I will try:

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

Do you describe this?

You asked if this is “good practice,” and I can tell you that it looks very strange, so no, it’s not.

You get nothing by doing this. You cannot have more than one Level , which does not bring any benefits, but this can cause problems in the future.

I did not understand your last paragraph, where you say that you made most of the things static to save memory. Usually you create one Level and it will be passed (without cloning) to different classes / methods that read or modify it.