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

Static variables are generally considered bad because they represent global state and are therefore much more difficult to reason about. In particular, they break the assumptions of object-oriented programming. In object-oriented programming, each object has its own state, represented by instance (non-static) variables. Static variables represent state across instances which can be much more difficult to unit test. This is mainly because it is more difficult to isolate changes to static variables to a single test.

That being said, it is important to make a distinction between regular static variables (generally considered bad), and final static variables (AKA constants; not so bad).

Answer 2

There are plenty of good answers here, adding to it,

Memory: Static variables are live as long as the class loader lives[in general till VM dies], but this is only in-case of bulk objects/references stored as static.

Modularization: consider concepts like IOC, dependencyInjection, proxy etc.. All are completely against tightly coupling/static implementations.

Other Con's: Thread Safety, Testability

Answer 3

Static variables are not good nor evil. They represent attributes that describe the whole class and not a particular instance. If you need to have a counter for all the instances of a certain class, a static variable would be the right place to hold the value.

Problems appear when you try to use static variables for holding instance related values.

Answer 4

There are 2 main problems with static variables:

• Thread Safety - static resources are by definition not thread-safe
• Code Implicity - You do not know when a static variables is instantiated and whether or not it will be instantiated before another static variable

Answer 5

I've played with statics a lot and may I give you a slightly different answer--or maybe a slightly different way to look at it?

When I've used statics in a class (Members and methods both) I eventually started to notice that my class is actually two classes sharing responsibility--there is the "Static" part which acts a lot like a singleton and there is the non-static part (a normal class). As far as I know you can always separate those two classes completely by just selecting all the statics for one class and non-statics for the other.

This used to happen a lot when I had a static collection inside a class holding instances of the class and some static methods to manage the collection. Once you think about it, it's obvious that your class is not doing "Just one thing", it's being a collection and the doing something completely different.

Now, let's refactor the problem a little: If you split your class up into one class where everything is static and another which is just a "Normal Class" and forget about the "Normal Class" then your question becomes purely Static class vs Singleton which is addressed in length here (and probably a dozen other questions).

Answer 6

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?

You have to balance the need for encapsulating data into an object with a state, versus the need of simply computing the result of a function on some data.

Moreover statics reduce the inter-dependencies on the other parts of the code.

So does encapsulation. In large applications, statics tend to produce spaghetti code and don't easily allow refactoring or testing.

The other answers also provide good reasons against excessive use of statics.