Hi. I'd like to know if there is any overhead in using static variables. I
like to use them because the code is cleanner than when I'm using objects.
But I don't know what are the negative aspects of doing that. I don't have a
lot of static variables in my classes, but I have a lot of static methods. I
think there is no problem with the methods.
Can anyone help me?
Thanks
Jon Skeet [C# MVP] - 21 Feb 2005 22:21 GMT
> Hi. I'd like to know if there is any overhead in using static variables. I
> like to use them because the code is cleanner than when I'm using objects.
> But I don't know what are the negative aspects of doing that. I don't have a
> lot of static variables in my classes, but I have a lot of static methods. I
> think there is no problem with the methods.
> Can anyone help me?
If a lot of your code is cleaner when using static methods, that's
often (but not always) a sign that you don't have the right classes to
start with.
The negative aspects of static methods stem from the lack of a lot of
the benefits of object oriented programming - most notably
polymorphism.
In fact, you may well find that static methods are very slightly faster
than instance methods, but in either case the difference is very
unlikely to be even slightly significant in any real application. Code
for what is most readable - but if you find yourself writing a lot of
static methods, consider changing your object model.

Signature
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Ice - 15 Mar 2005 03:27 GMT
It amazes how many developers love the "static" for ease of programming.
ice
> > Hi. I'd like to know if there is any overhead in using static variables. I
> > like to use them because the code is cleanner than when I'm using objects.
[quoted text clipped - 16 lines]
> for what is most readable - but if you find yourself writing a lot of
> static methods, consider changing your object model.
Brock Allen - 15 Mar 2005 03:38 GMT
> It amazes how many developers love the "static" for ease of
> programming.
>
> ice
Ice,
Can you elaborate on the point you were getting at?
-Brock
http://staff.develop.com/ballen
Ice - 15 Mar 2005 04:00 GMT
the point was that, my developers prefer doing things like:
StaticClass.Method(parameters)
verus
InstanceClass class = new InstanceClass(instanceData)
class.Method()
Totally minimizing the ability to extend the classes i.e. let's avoid having
state in the class, so i can call a static method and pass all the data I
need in. The only classes that I really think should be designed for static
use only, are "helper classes".
ice
> > It amazes how many developers love the "static" for ease of
> > programming.
[quoted text clipped - 7 lines]
> -Brock
> http://staff.develop.com/ballen
Brock Allen - 15 Mar 2005 04:21 GMT
> the point was that, my developers prefer doing things like:
> StaticClass.Method(parameters)
[quoted text clipped - 5 lines]
> the data I need in. The only classes that I really think should be
> designed for static use only, are "helper classes".
I understand this is a limited example, but I think I'd tend to disagree
with you here. Primarily because I can't tell what benefit InstanceClass
is giving me in this scenario. Creating an object for the sake of doing "OO"
programming isn't proper OO programing. OO programming is intended to model
entities that hold state and to hide complexity. Also, it's silly to create
a temporary heap based object to only call a single methid then give it back
to the GC. statics are an excellent tool in the dev's toolbox (as are classes
and objects). Each has its own purpose and utility.
I know I'm probabaly starting a religious debate here (it wasn't my intent).
:D
-Brock
http://staff.develop.com/ballen
Ice - 15 Mar 2005 14:07 GMT
Well you can't tell what benefits its giving because its a limited example
and its usage context is not fully displayed. In theory, you could design
everything to be static (avoid state or introduce a boatload of
synchronization) and pass everything into the class just for an "easier?"
programming model.
I think that "staticity" is a feature of a class and if the only features a
class has are "statics" then so be it. It's my experience that "helper
classes" fall more in this category than classes that model actual business
operations.
I think we agree more than you think.
ice
> > the point was that, my developers prefer doing things like:
> > StaticClass.Method(parameters)
[quoted text clipped - 20 lines]
> -Brock
> http://staff.develop.com/ballen
Brock Allen - 15 Mar 2005 14:33 GMT
> I think we agree more than you think.
Probabaly :)
-Brock
DevelopMentor
http://staff.develop.com/ballen
John Puopolo - 22 Feb 2005 19:22 GMT
Ricardo:
Another thing to watch for is concurrent access to static data. In
mutlithreaded situations, access to static variables must be synchronized.
In C#, you can use the lock statement.
John Puopolo
> Hi. I'd like to know if there is any overhead in using static variables. I
> like to use them because the code is cleanner than when I'm using objects.
[quoted text clipped - 4 lines]
>
> Thanks
Michael D. Ober - 22 Apr 2005 21:10 GMT
OK - now that we've had the discussion on the pros and cons of static
methods, with no resolution, it's time to address OPs original question of
static variables. Ricardo, can you give an example of what you're trying to
do. As a general rule, static variables are reference via the application's
global data storage and will consume memory for the life of the program. I
do tend to agree with one of the poster's comments that if your code is
cleaner using statics than with objects, you may not have properly factored
your problem. This is why we need an example.
Mike Ober.
> Hi. I'd like to know if there is any overhead in using static variables. I
> like to use them because the code is cleanner than when I'm using objects.
[quoted text clipped - 4 lines]
>
> Thanks