21

Possible Duplicate:
Why are static variables considered evil?

I have the habit of using static variables extensively in all my programs, especially when I am working with Android. I tend to use them because sometimes it feels so cumbersome to send 10 or more values via Intents. So, I just declare them as static variables and access them in the other classes easily by using the "dot" operator. Another reason for using static variables is when I am making a Utility class to be used throughout my application. Like the code I have given below helps me to use the variables in different activities.

Utility.java

public class Utility {
public static Facebook fb;
public static AsyncFacebookRunner fbAsyncRunner;
public static String[] fbPermissions = {"email", "read_stream", "user_birthday"};
public static final String PREF_UTILITY_FILE_NAME = "PrefUtilityFile";
public static SharedPreferences prefs;
public static Editor editor;
public static String access_token;
public static long expires;
}

I searched online for similar questions and came across this and this, but they do not seem to give a final answer to the issue. And in most of the places, I see conflicting opinions and hence am totally confused.

Is it a good programming practice or bad ? Should I be using it or not ?

Community
  • 1
  • 1
Swayam
  • 16,294
  • 14
  • 64
  • 102
  • 3
    [Spaghetti code](http://en.wikipedia.org/wiki/Spaghetti_code) – auselen Sep 19 '12 at 10:35
  • Personally I'd say bad as you are simulating global vars. Have a look at the builder pattern. – RNJ Sep 19 '12 at 10:36
  • The way you're using them? Bad. – JoeG Sep 19 '12 at 10:38
  • 1
    Not really asnwering your question so i'm doing a comment instead. If i face a code like this what i look for if the stored things are related. Classes called Utility are 90% of all cases are like a wasteyard. A collection of unrelated stuff. – dbalakirev Sep 19 '12 at 10:38
  • @Nanne : Thanks for pointing it out, but I had already added the link to that "duplicate" question in my own question. – Swayam Sep 19 '12 at 10:42
  • 1
    But them having no final answer doesn't mean it is not a duplicate. The fact that there are conflicting opinions is also not a reason to start a second question, so that's why i marked it as duplicate. – Nanne Sep 19 '12 at 11:10

5 Answers5

18

You can replace all you static fields with a "Context" object which you can pass around or make a Singleton. It is possible to remove almost all your static fields away. Whether this is a good idea or not is up to you, but I wouldn't assume that it has to be much harder to use instance fields.

BTW: I would suggest

  • placing static fields/constant with the class or package which uses them
  • treat static arrays as immutable if possible making them final as well.

You can use a non-static Context with 

public class Context {
    public static final String PREF_UTILITY_FILE_NAME = "PrefUtilityFile";

    public Facebook fb;
    public AsyncFacebookRunner fbAsyncRunner;
    public String[] fbPermissions = {"email", "read_stream", "user_birthday"};
    public SharedPreferences prefs;
    public Editor editor;
    public String access_token;
    public long expires;
}

// pass to constructor as required
class UsesContext {
    final Context context;
    public UsesContext(Context context) {
        this.context = context;
    }

    public void method() {
        // can use context
    }
}

This allows you to create unit tests with multiple Contexts.

The only thing I would leave static are constants.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks for your suggestions, but could you please explain a little more about how I can use my variables in different Activities using a context object ? I have used the context object to make Toasts and other stuffs, but how do I access variables using context ? – Swayam Sep 19 '12 at 14:32
  • Awesome! I wish I could vote it up more than once! Thanks a lot! – Swayam Sep 19 '12 at 14:44
  • 1
    @PeterLawrey I wouldn't use 'Context' as the exact name of a class, since it is an existing class in the Android Framework. – IgorGanapolsky Jul 10 '14 at 19:27
  • @PeterLawrey why not have a private variables and public getters and setters ? basically encapsulation. – Punith Raj Jun 22 '15 at 16:06
  • 1
    @PunithRaj encapsulation could be an improvement. esp if this class is being used by code you cannot easily change. However if you have access to all the code which uses this class, adding getters/setters will just complicate the code. Making the field package local and `final` where possible would also help. – Peter Lawrey Jun 22 '15 at 18:25
7

I am all for static variables if you keep using them regularly and the values never change if you make them final.

Why do things the difficult way?

That is what static variables are all for.

Basically what they do is provide a generic access point you can access from any context(static, program flow, external).

You are basically stating the front door is here and it's yellow. Someone peeking from the outside will see the door which is yellow. Someone on the inside walking will see the door and that it's yellow. Someone in a room can look into the hallway and see that it's yellow.

And if you paint it red, it will be clearly visible to everyone.

Also, there will always be 1 instance throughout the ENTIRE program with the same value. which saves memory.

take for example

class test {
public int ten = 10;
   public test() {
   }
}

Every time you make a new test() an integer memory space will be assigned for the ten variable. So if you have 10 test instances you will have 10 seperate integers all holding the same value.

if you have this

class test {
public static int ten = 10;
   public test() {
   }
}

and you have ten test instances, you will only have one integer instance ten. This saves memory assignment, garbage collection. Although I only advice this for persistent lists/variables that do not change and you can afford to keep in memory indefenately. Don't do this with every variable. Do this for large things like an image that you re-use over and over. No use to keep the same image in memory multiple times.

When I originally wrote my answer I didn't know how static variables really worked. I got static final and static mixed up. On static variables you can assign new values. static final are immutable. those can't be changed.

Tschallacka
  • 27,901
  • 14
  • 88
  • 133
7

This programming practice is bad in purely object oriented languages (like Java) because it undermines the object oriented programming paradigm. They work, but once you realize you DO need more than one version of them, you will need a lot of refactoring to achieve that.

If you think that handing too many parameters via method calls is cumbersome. Simply create an object that holds all of them (see Peter Lawrey's answer, "Context" object) and pass only this object. Then you can again use your "simple dot notation" on that object.

Next point: Testing. If you need to replace some static fields with proxy or other testing stuff for unit tests, you are basically screwed. With a context object, you can simply hand a different context object into the unit tests.

The Utility class you mentioned is basically a good candidate for such context object. Simply make all its fields non-static and hand in an object of that class to code that needs it.

I can tell you about one example where I got screwed by using statics: I once wrote a compiler. And since I thought that during a compilation run, there are many context things that are only necessary once (the symbol table, for example), I added them all as static variables. Later I decided to allow multi-threaded compilation and a "server" mode where the compiler runs all the time in idle mode until a client sends a compile request (this saves Java's long startup time). Now I was screwed. Now there was more than one concurrent context (concurrent compiler threads), but all context was shared via static variables. I needed around one week to replace all statics by context objects and introduced numerous bugs.

gexicide
  • 38,535
  • 21
  • 92
  • 152
  • Your experience is a great example where using static variables could backfire. Thanks for sharing it! – Swayam Sep 19 '12 at 14:29
  • This isn't a great example although not a bad one too. If you've designed your application to be single threaded first and then design it to be multi-threaded, lots of other things would break too along with static. Even normal state variables which would be shared, file i/o and other state dependent things would break too. That's because you've to design it according to new paradigms different what you followed earlier. You could've solved it by forking another process too if you wanted to follow the same single threaded design but still have parallel tasks. – Abhinav Gauniyal Sep 19 '16 at 15:54
  • @AbhinavGauniyal: But a compiler server is a very simple shared nothing architecture. Two compile requests have almost nothing in common, so making concurrent compilation available should not be a big task. But static state made it a big task. Of course, I agree, that turning a single threaded program into a concurrent one is usually never easy, but static state makes it unnecessarily cumbersome. – gexicide Sep 19 '16 at 21:14
  • Last part of this answer, answered my question thanks!. – Blasanka Aug 14 '17 at 11:21
3

Bad. See Cutting out Static.

In my opinion, static variables comprise one or more objects, but that objects are ill-formed: not organized in classes (no type hierarchy), bad encapsulation, limited to single instance (this may cause trouble when in future, multiple instances required).

Alexei Kaigorodov
  • 13,189
  • 1
  • 21
  • 38
3

Variables that are declared static stays in the memory till the program executes thus taking extra space.

The use of static may be beneficial if you want to use/retain a value for a long period of time, however declaring all variables as static is not recommended and is not a good practice . If you make a habit of declaring all value as static your program will eat unnecessary memory.

Other than that static variable doesn't comply with OOPS concept where scopes, abstraction and encapsulation are defined along with the effervescence object. Through which you can call and delete variables at will.

The biggest disadvantage of using static variables will appear if you are working in limited memory space (such as mobile applications) in that case you application will crash if it is overhogged by variables and less memory space.

If you want to store a value permanently there are other ways around like database, files etc makes the job easier and cleaner. Just my 2 cents.

Shashwat
  • 269
  • 1
  • 3
  • 9
  • ~"Variables that are declared static stays in the memory till the program executes thus taking extra space." There is a big difference between public static variables and private static. – IgorGanapolsky Jul 10 '14 at 19:32