Static on the Radio
Tuesday, May 10, 2011 at 07:25PM 
I was doing a C# revision lecture yesterday and I was talking about static class members. I mentioned the fact that every year some students write “Static means that the value of the variable cannot be changed” in the exam, which produces an anguished cry from me and zero marks. I was trying to think of a better way to explain what static really means. And I thought about the radio. If you turn on your am radio and tune it away from a station you will hear static. And that static hiss is always there. It has been there since before radios were invented and it will be there until the universe cools right down. Static class members are a bit like this. They are always there. They exist whether you make an instance of the class or not. Static in this situation doesn’t mean “can’t change” it means “always there”.
We use them in programs when we want a data member that is part of a class but not part of each instance. For example, in a bank we might have loads of accounts, but the minimum amount you can withdraw, the maximum size of the balance we can have and the minimum age for an account holder are all relevant to accounts, but not stored in each account instance. Static works well in this situation.
Programming, Teaching
Reader Comments (5)
And then we have Singletons, which is a pattern, so that must be good. But a simple static variable seems to do the job anyway.
I think static is a more advanced idea that gets introduced to programmers too early just to make something work, and really you have to understand object properly before you can appreciate what static really means. For example, I'd like to hope that at the end of the month my salary is always there in my bank account, but it's clearly not an appropriate candidate for a static variable.
I prefer to call static part of the class and not of the instance of the class, but to understand that you have to know what a class is, and what an instance is.
@Jules, you seem to have a reasonable appreciation of classes and what static means, and you're also right in that you can abuse static to achieve things that would better be done in other ways. You can abuse static to make global variables, and a singleton is kind of a way to make one naughty little global variable to give access to a lot of other variables with on global instance. There are places where singletons are appropriate, but they can also be abused as ways to get data to places in a lazy way. There are pros and cons with singletons too. Most of them are to do with things like exactly when singletons are created and destroyed, and thread safety. That isn't to say all singletons are bad, but before you use one you need to consider if it is appropriate, or if it's just laziness.
I think what you have to consider here is really an issue of risk. Your customer will not care if you use static, or singletons, or double overhead underarm tripple cambered and cantelevered bridge classes. As long as the program works. But by making things static and generally easy to get at and meddle with, you are increasing the risk that someone will use something in a way you hadn't planned, and cause your program to become unreliable. For me, the fewer risks I run, and the easier it is for me to manage the use of data, the better. And I regard static data as a risk I need to be aware of.