Currently in a Win Form application, im using a Global Variable Class which contains variables that are used to to share data. My question is, what other ways are there to achieve this? Best practises? and why?
-
I think your going about programming the wrong way. In procedural programs (and many unmanaged apps) you have global variable classes or modules. Its not good, one slight change and the state of the application can become corrupt very easily. The better way is to limit variables to the scope they are needed in a OOP way & use the App.Config. – Jeremy Thompson Dec 22 '12 at 00:14
-
@JeremyThompson App.Config is global state :) – Steven Doggart Dec 22 '12 at 02:27
-
yes, I'm hinting to OP to put the global settings such as connection string in the App.Config. – Jeremy Thompson Dec 22 '12 at 03:03
-
@JeremyThompson I figured I agreed with where you were going with it. I just hate the way the App.config is used, quite often, where deep in some class library somewhere it reads directly from the App.config, without your knowledge, and acts differently depending on what it finds. Doing things like that goes against every principle of DI and is just as bad as globals, yet its very prevalent even in the .NET framework, itself! I certainly use the App.config just for consistency and convenience, but I always load all my settings once and then pass them around as needed. – Steven Doggart Dec 22 '12 at 09:10
2 Answers
Globals are bad for many reasons, but probably the most glaring reason is because, ideally speaking, every time you call the same method, passing it the same parameters, it should always do the same thing with the same results. Globals brake that rule. Suddenly your code starts behaving in unpredictable ways because something wasn't initialized properly somewhere else, or some global got modified incorrectly.
The best way I've found to get rid of the need for globals is to adhere to the principles of dependency injection (DI). There is much material on the topic online, but in a nutshell, rather than having classes reach out to create or find their dependencies on their own, they should simply request that the dependencies be provided to them, often in the constructor. Anything that you are accessing via global variables would, by definition, be considered dependencies of the classes that access them. Therefore, instead of, for instance, having a global settings object, like this:
Global settings As New Settings()
And then a class that uses it like this:
Public Class MyClass
Public Sub DoSomething()
If settings.SomethingEnabled Then
' ...
End If
End Sub
End Class
You would instead, do it like this:
Public Class MyClass
Public Sub New(settings As Settings)
_settings = settings
End Sub
Private _settings As Settings
Public Sub DoSomething()
If _settings.SomethingEnabled Then
' ...
End If
End Sub
End Class
This makes your code much cleaner, more flexible, and more reliable. It also makes the code far more testable too, which is a great added benefit.

- 43,358
- 8
- 68
- 105
-
1+1 and with this methodology its easy to implement an interface (DoSomething) for unit test mocking support. ps I always find mocking the Config/Global settings plays a big part in unit testing... – Jeremy Thompson Dec 22 '12 at 03:07
Data should be shared according to how it is going to be used. If a variable is required across the entire application then it can be seen to have global scope and a global variable concept (e.g. public static shared) may well be appropriate.
Often this is not the case however as global variables should really be avoided (check out here and here for more reasoning)
Data should be encapsulated at the level it is required - for example if a form has data / variables within it that are applicable to it's function but where other forms need to now the value, this would be the ideal case for a public readonly property on the form, which would mask the actual detail of the variable from the rest of the aplication.