Global Variable Alternatives

E

ehelin

Freshman
Joined
Oct 11, 2005
Messages
48
Hi:

I am frequently faced with a question of how to set states in my application. Things like...is the load complete? should a text box behave one way or another? Things that depend on the state data persisting outside the method/event handler in question. No problem, just set a class variable global to the form and problem solved.

However, my boss is wanting me to get rid of as many of these global variables as possible...I am accomplishing some of this through encapsulation. However, things like the load event being complete...or other functionality that depends on the state data is a harder nut to crack. Normally, this wouldn't be that much of a bad thing...but most of our applications revolve around one form...all other things spring from this parent form and well, the functionality can be come quite intricate depending on our users and specific application.

I would be interested on hearing anyone else's thoughts on how to get rid of global variables, but retain the state data that events/methods are dependant on.

Thanks!

Eric
 
Addition to original post

Sorry, meant to mention that these variables are only global to the form, not the application. A typical declaration would be:

Private VarLoadComplete as boolean = false

Since our applications revolve around one form, even though this is not a global variable in the sense of:

public static VarLoadComplete as boolean = false

they tend to be in our type applications.

Thanks!

Eric
 
The correct term, I suppose, would be "class scope."

This is a problem I used to have before I really got the hang of object-oriented programming. I understood the object-oriented concepts but didn't know the different ways that I could take advantage of them to make life easier. To cut down on the clutter of a large number of variables all declared in one class takes a combination of solutions, most of which are manifestations of object-oriented programming concepts.

One big thing that reduces code clutter (at least in my programs) is to extend controls through inheritance rather than extarnal machanisms, or, in other words, to inherit a control to add functionality to it rather than adding variables and functions to the form the control will go on. For instance, if you have a button the user clicks to bring up a date dialog, instead of adding a click handler function, a variable to store the date, code to display the dialog, etc., create a DateButton class that derives from the Button class. Have all the interation code (dialog popup, button's text) put in the DateButton file. Create a Date property and a DateChanged event and it is ready to be dropped on your form, fully functional while adding very little code to the form's code file.

Another suggestion would be to create structures or classes to hold related groups of data. Instead of having variables UserName, UserID, UserIP, UserIsAdmin, etc., you could create a structure to store all that data in and have only a single variable in your form's code.
 
I'd have to agree with much of what marble_eater suggested. When I started programming I often found that I would have multiple boolean states but only one of them could be true at once, as such all the booleans could be replaced with a state enum.
 
Back
Top