Should I avoid using static vaiables

I am developing a java API (and not an API for sure) in my office that will contain 4000+ constants. Thus, all teams can use them directly. Initially, I was thinking of creating my classes according to their type and creating my static objects in a separate class. Therefore, anyone can use them directly.

But after reading the need for a static variable , I am afraid that it might be a problem to create so many static variables. Is there an alternative?

* After me, someone who joins this project can also add a constraint to my Constant class without worrying about performance. It is likely that many of the constants will be rarely used.

* Each member of the Constant class will represent a class that will have its own behavior. This may be part of some inheritance tree further. Therefore, using an enumeration may not be a very good idea.

+4
source share
4 answers

You want to create a place where about 4000+ constants will live. Is there any chance that users of this class can add constants (possibly at runtime)? T

  • Concern over static memory issues is inappropriate. If you need 4,000 values, they will have to live somewhere, right?

  • If people add values ​​at runtime, it sounds like a singleton map or properties (which is really just some kind of map) anyway. People often use dependency injection frameworks such as Spring or Guice to manage such things.

  • If you just want to add compilation constants, you can make them static. You probably want to also make them static, they will be compiled inline.

  • It is very likely that 4,000 constants is a very bad idea. Where I have seen systems with a large number of constants (> 100, even) defined in one place, it usually happens that people forget their definitions and end up using their options, which leads to target defeats (for example, I worked on a system with 100 SQL queries defined in the “Queries” class. Of course, people immediately ignore this, because they worry more about whether you need an exact query and not collapse your own. The class eventually grew to about 1,500 queries, many exact copies and many unused, most use x once. It is pointless). I can imagine exceptions in which you won’t “lose” things with naming conventions, but if you don’t have such a use case, this seems like a really bad idea.

  • Destroying your enumeration constants gives you safe links. It also makes things conceptually easier to solve. For comparison:

-

public class Constants { String WORK_ADDRESS; String WORK_PHONE; String HOME_ADDRESS; String HOME_PHONE; } 

with

 public enum ADRESS{ WORK, HOME } public enum PHONE { WORK, PHONE } 

What would you like to work with?

+4
source

Performance is unlikely to be a problem with this design. RAM is cheap. (Repeat the usual quote: premature optimization is the root of all evil.)

On the other hand, I'm not quite sure how any client developer can remember and use 4000+ constants. Can you give us an idea of ​​what this object is?

You may, depending on the details that you did not give us, find it useful to collect constants in enum s. Standless enumerations may be easier to understand than public static final variables if there are some natural groupings that you can use.

+3
source

What happens when you highlight in static is that it will not be released at runtime of your application.

and what?

if you do not create them static, they will be duplicated through each instance of your classes.

what you do not want to do is to set up huge static volumes of data, such as images or a graphical user interface, an image takes up much more than a few fields;

4000 constants, undoubtedly int (4 octets) = 16000 octets, even the size of the icon ^^

I would like to point hte Javadoc to prove my point

http://download.oracle.com/javase/1.4.2/docs/api/constant-values.html#java.awt.event.KeyEvent.CHAR_UNDEFINED

this is a KeyEvent declaration in Java, check out ^^ declarations

+2
source

Unless you create large arrays or very long strings, 4000 data values ​​will not have a large amount of memory. I think you mentioned that you talked about a lot more data.

Another approach is to read the values ​​from the settings file.

Perhaps the constants will be modulated into a set of classes, so the more rarely used ones will be loaded only on demand.

+2
source

All Articles