Why are static variables considered evil?

Question

I am a Java programmer who is new to the corporate world. Recently I\'ve developed an application using Groovy and Java. All through the code I wrote used quite a good numbe

Answer 1

Seems to me that you're asking about static variables but you also point out static methods in your examples.

Static variables are not evil - they have its adoption as global variables like constants in most cases combined with final modifier, but as it said don't overuse them.

Static methods aka utility method. It isn't generally a bad practice to use them but major concern is that they might obstruct testing.

As a example of great java project that use a lot of statics and do it right way please look at Play! framework. There is also discussion about it in SO.

Static variables/methods combined with static import are also widely used in libraries that facilitate declarative programming in java like: make it easy or Hamcrest. It wouldn't be possible without a lot of static variables and methods.

So static variables (and methods) are good but use them wisely!

Answer 2

Static variables most importantly creates problem with security of data (any time changed,anyone can change,direct access without object, etc.)

For further info read this Thanks.

Answer 3

Evil is a subjective term.

You don't control statics in terms of creation and destruction. They live at the behest of the program loading and unloading.

Since statics live in one space, all threads wishing to use them must go through access control that you have to manage. This means that programs are more coupled and this change is harder to envisage and manage (like J Skeet says). This leads to problems of isolating change impact and thus affects how testing is managed.

These are the two main issues I have with them.

Answer 4

I find static variables more convenient to use. And I presume that they are efficient too (Please correct me if I am wrong) because if I had to make 10,000 calls to a function within a class, I would be glad to make the method static and use a straightforward class.methodCall() on it instead of cluttering the memory with 10,000 instances of the class, Right?

I see what you think, but a simple Singleton pattern will do the same without having to instantiate 10 000 objects.

static methods can be used, but only for functions that are related to the object domain and do not need or use internal properties of the object.

ex:

public class WaterContainer {
    private int size;
    private int brand;
    ...etc

    public static int convertToGallon(int liters)...

    public static int convertToLiters(int gallon)...

}

Answer 5

My $.02 is that several of these answers are confusing the issue, rather than saying "statics are bad" I think its better to talk about scoping and instances.

What I would say is that a static is a "class" variables - it represenst a value that is shared across all instances of that class. Typically it should be scoped that way as well (protected or private to class and its instances).

If you plan to put class-level behavior around it and expose it to other code, then a singleton may be a better solution to support changes in the future (as @Jessica suggested). This is because you can use interfaces at the instance/singleton level in ways that you can not use at the class level - in particular inheritance.

Some thoughts on why I think some of the aspects in other answers are not core to the question...

Statics are not "global". In Java scoping is controlled separately from static/instance.

Concurrency is no less dangerous for statics than instance methods. It's still state that needs to be protected. Sure you may have 1000 instances with an instance variable each and only one static variable, but if the code accessing either isn't written in a thread-safe way you are still screwed - it just may take a little longer for you to realize it.

Managing life cycle is an interesting argument, but I think it's a less important one. I don't see why its any harder to manage a pair of class methods like init()/clear() than the creation and destroying of a singleton instance. In fact, some might say a singleton is a little more complicated due to GC.

PS, In terms of Smalltalk, many of its dialects do have class variables, but in Smalltalk classes are actually instances of Metaclass so they are really are variables on the Metaclass instance. Still, I would apply the same rule of thumb. If they are being used for shared state across instances then ok. If they are supporting public functionality you should look at a Singleton. Sigh, I sure do miss Smalltalk....

Answer 6

Suppose that if you have an application with many users and you have defined a static function that saves state within a static variable, then every user will modify the state of other users.