Global variables v Settings in C#

Question

I have read in various places that having variables with global scope, i.e. a public static class with static members, is considered going against the philosophy of OO, and is not good design. (For example, I have seen comments along the lines of: "If you are using a global, you are not doing it right." Or words to that effect.)

But, if you use the Settings mechanism provided by Visual Studio, e.g. "Settings.Default.MySetting" etc, this is available globally throughout an app, so how does this differ from using a public static class?

Also, the same results can be achieved by using a singleton object, but this also provokes various opinions, to say the least.

Global variables are just SO useful, (VB Module, anyone?), but I'm trying to teach myself how to do this OO malarky properly, so, if global variables smell bad from an OO point of view, what is an alternative?

I'm particularly interested on people's opinions of the use of the 'Settings' functionality. Is this considered good OO design?

Thank you for any comments.

Answer 1

Static methods and other members aren't bad practice in their own right. It is just that people less familiar with OO concepts tend to litter their code with static methods, properties and fields everywhere, without realising what the consequences are.

Generally, for things like configuration settings, helper and utility classes, abstract factories, singletons etc., having static members is perfectly acceptable.

Answer 2

A public static class or member is not always a bad idea (even if it's not perfectly OO). Many good OO designs use a public static member for things like Loggers or Settings (as you point out). A good example of how do this in a OO way is the Static Gateway.

Answer 3

Global variables, like gotos, are something that should be avoided by all beginners, but are extremely useful to an advanced programmer.

I would say that if you do not feel confident and you do not have a specific, justified reason why it is a good application of them, do not use them. Master OO before resorting back to global variables.

Answer 4

The Settings mechanism... hmm...

I look at those mainly as part of the environment. Like the OS or Time, but for the application. They aren't really "variables" like you'd declare during an INIT.

However, you could wrap an object around them and only access them via that object, instead of reading them whenever they were needed at runtime. I haven't tested it, but it's probably a performance wash (or negative towards reading them raw if you don't do good memory management).

Eventually, as applications mature, things like this end up getting objects wrapped around them anyway. My rule is, whenever I start thinking, "nah, this is too simple, too atomic, and won't require an object..." that's my clue to make it an object.

Answer 5

In C# you're going to have a hard time going against good OO design because you cannot get away from OO. It's not like C++ where you can mix and match structured with OO programming -- the realm in which these kinds of arguments often occur. Static members on a class are OO. So are Microsoft's generated Settings because code generation creates OO encapsulation for them or at least an "object container" around them. So they're never global variables because that doesn't exist in C# - they are just static members on classes -- nothing there that's non-OO.

If the argument is about singleton vs static members then it's pitting one OO argument against another OO argument.

Then there's always the philosophical viewpoint vs practical viewpoint. In most realms the ideal philosophical viewpoint being implemented is not really worthwhile on its own except for academic study. Real world needs real solutions, mixed solutions.