CODEWITHSUNDEEP
c#global-variables
Kasper Holdum
Kasper Holdum

Reputation: 13363

When to use static variables?

I'm currently doing a project in C# with a lot of rendering, and throughout almost all the classes there's a constant value of the type integer being used for scaling of the rendering. I know I could define this constant in one place as a normal variable and then pass it around, but this seemes really cumbersome. When is it acceptable to use static variables in C#? The easiest solution to my problem would be to create a class containing the static variable that all the other classes could reference - would that be bad design?

Upvotes: 3

Views: 8747

Answers (5)

Alun Harford
Alun Harford

Reputation: 3124

If all your classes have to understand this value + do something else, then (unless it's something like pi) you probably should check that your classes have a single concern. Perhaps that 'value' needs to become an object that can do the operations that are currently being done all over your codebase?

Upvotes: 1

Marc Gravell
Marc Gravell

Reputation: 1062745

How constant is the value? static is fine for things that are readonly, but you can quickly get into a mess if it isn't readonly - especially if you have multiple threads. The scaling factor doesn't sound like a hard constant to me - i.e. it isn't:

public const double ScaleFactor = 1;

I wouldn't hesitate to use a static variable for something I load once and leave alone. Other than that, I'd probably encapsulate (in your case) some kind of RenderContext with this value and any other utility methods - and pass the RenderContext between methods; this can also help you abstract away from the underlying implementation if you need to unit test, etc.

As you find you need more properties (and you inevitably will), you just extend the RenderContext class - nothing else changes.

(edit)

Also - consider the future: will you ever be doing more than one render at once? Since we all have lots of cores now, etc... static is good if all the threads share a value. There is [ThreadStatic], but that is a bit messy by comparison.

Upvotes: 8

Craig
Craig

Reputation: 12012

The answer is that if the program works and is maintainable, do it.

Static variables aren't a sin, it is just good to know when to use them. :)

Upvotes: 2

JP Alioto
JP Alioto

Reputation: 45117

Not bad design at all. In fact, having a Common or Utility namespace and class that exposes static methods and static values centralizes these values in one place so you can ensure that every module in you application is using the appropriate values. It's low cohesion, but acceptable for the benefit. I see no problem with it.

Upvotes: 7

BFree
BFree

Reputation: 103740

No, that would actually be a perfect candidate for static variables. You can even go one step further and make the class static, so that it can't be instantiated. You can then add all your constants to that class as well as some helper methods if necessary.

Upvotes: 6

Related Questions