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've used quite a good number of statics. I was asked by the senior technical lot to cut out on the number of statics used. I've googled about the same, and I find that many programmers are fairly against using static variables.
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?
Moreover statics reduce the inter-dependencies on the other parts of the code. They can act as perfect state holders. Adding to this I find that statics are widely implemented in some languages like Smalltalk and Scala . So why is this oppression for statics prevalent among programmers (especially in the world of Java)?
PS: please do correct me if my assumptions about statics are wrong.
Source: Tips4all
Static variables represent global state. That's hard to reason about and hard to test: if I create a new instance of an object, I can reason about its new state within tests. If I use code which is using static variables, it could be in any state - and anything could be modifying it.
ReplyDeleteI could go on for quite a while, but the bigger concept to think about is that the tighter the scope of something, the easier it is to reason about. We're good at thinking about small things, but it's hard to reason about the state of a million line system if there's no modularity. This applies to all sorts of things, by the way - not just static variables.
Evil is a subjective term.
ReplyDeleteYou 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.
No. Global states are not evil per se. But we have to see your code to see if you used it properly. It is quite possible that a newbie abuses global states; just like he would abuses every language feature.
ReplyDeleteGlobal states are absolute necessity. We cannot avoid global states. We cannot avoid reasoning about global states. - If we care to understand our application semantics.
People who try to get rid of global states for the sake of it, inevitably end up with a much more complex system - and the global states are still there, cleverly/idiotically disguised under many layers of indirections; and we still have to reason about global states, after unwrapping all the indirections.
Like the Spring people who lavishly declare global states in xml and think somehow it's superior.
@Jon Skeet if I create a new instance of an object now you have two things to reason about - the state within the object, and the state of the environment hosting the object.
There are 2 main problems with static variables:
ReplyDeleteThread 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