Should i avoid using STATIC vaiables

I am designing a java API(not an API exactly) in my office which will contain 4000+ constants. So all the teams can use them directly. Initially i th开发者_JAVA百科ought to create their classes according to their type and create their static objects into a separate class. So anybody any use them directly.

But after reading need of static variable, i afraid it could be a problem of creating so many static variables. Is there any alternate?

*After me whoever will join this project can also add a constraint in my Constant class without caring of performance. There is a possibility that many of the constants will be used rarely.

*Every member of Constant class will represent a class which will have its own behavior. It might be the part of some inheritance tree further. So using enum might not be a good idea.

You want to create a location where some 4000+ constants will live. there's the possibility that users of this class may add constants (possibly at runtime)?. T

• Concern about the memory issues of statics is misplaced. If you need 4000 values, they're going to have to live somewhere, right?

• If people will be adding values at runtime, this sounds like a singleton Map or Properties (which is really just a kind of map anyway) of some kinds. People often use dependency injection frameworks like Spring or Guice to manage this sort of thing.

• If you just mean adding compile constants, you can make them all static. You'd probably want to make them static final as well, they'll be compiled inline.

• It's very likely that 4000 constants is a very bad idea. Where I've seen systems with large numbers of constants (>100, even) defined in one place, what usually happens is that people forget the definitions of them and end up using their own variants , which sort of defeats the purpose (for example, I've worked on a system with 100's of SQL queries defined in a "Queries" class. Of course people immediately ignore it as it's more of a bother to look up if the exact query you need is in there than to roll your own. The class eventually grew to something like 1500 queries, many exact duplicates and many unused, most used once. Utterly pointless). I can imagine exceptions where you wouldn't "lose" things with naming conventions, but unless you've got a use case like that this seems like a really bad idea.

• Breaking out your constants into enums gives you type-safe references. It also makes things conceptually easier to deal with. Compare:

-

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 }

Which would you rather work with?

Performance is highly unlikely to be the problem with this design. RAM is cheap. (Cue 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 what sort of object this is?

You may, depending on details you haven't given us, find it useful to collect constants into enums. Stateless enums can be easier to understand than public static final variables if there are some natural groupings you can take advantage of.

What happens when you allocate in static is that it surely won't be freed in the runtime of your app.

so what ?

if you don't create them static then they'll be duplicated through every instance of your classes.

what you don't want to do is to set static huge amounts of data such as images or GUI an image takes up a lot more than a few fields;

4000 constants of surely int (4 octet) = 16000 octets not even the size of an icon ^^

I would point out 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 the KeyEvent decleration in Java, check the out declarations ^^

Unless you are creating large arrays or very long strings, 4000 data values isn't going to be a lot of memory. I think that post you cited was talking about much larger amounts of data.

Another approach is to read the values from a preferences file.

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