Global variables vs. passing arguments 1

[RebLazer]

This is a general programming question - not really VB.net specific, but I am not aware of a better forum to post this in - so I'm posting it my favorite forum, right here.

I remember learning in school that it's not good to declare objects globally; rather, it's better to pass needed objects into routines as arguments.

Why?

Thanks,
Lazer

 

[chiph]

It's actually very difficult to use global variables in .NET -- everything is a class
(unless you want to run in the penalty box of VB6 compatibility)

If you really have a need for global variables you can create a singleton instance of a class which will act as a holder for your values. (See

http://abstractvb.com/code.asp?A=1096

for info on building a singleton in VB.NET)

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[RebLazer]

Chiph,

Maybe "global" is the wrong term. I mean declaring a variable at the class-level when it will be used in a few subroutines.

Why would that be bad?

Thanks,
Lazer

 

[nomi2000]

Reb
You have to decided what varible scope you need VB .net suppot
Friend,Protected,Private,Global and other
now it depends upon ur scenirio i don't hesitate to use
Private in my class if that variable have to be visible in that class..every scope is used when its needed
Regards
Nouman

 

[RebLazer]

Nouman,

I am not refering to access modifiers, I mean the placement of the code - i.e. within a subroutine as opposed to a class-level variable, i.e. outside of any subroutine.

Lazer

 

[RoguePoet01]

I've just started VB.net, but I had no problem using "types" within modules.

Usually it just seems to work better when I pass the parameters. Types can be passed, too.

Back in college globals seemed to make a lot of sense, but the length of the code was much smaller, and it was easier to keep track of them.

I've usually had bad luck with globals, and always had to figure out a better way to do things.

The only globals I might still use are booleans to tell me if a certain thing has happened or not, so I can close out the program accordingly.

 

[chiph]

Reb -

There's no problem with declaring instance-level variables (variables declared at class scope). Everytime you create a new instance of your class, that instance gets a new copy of your class-level variables (aka: member-variables). You'll want to initialize them where they're declared, or in the New method.

Two things to watch out for:
1) Multi-threading. If you class has multiple threads of execution, you will need to restrict access to the member variables using the Monitor class from the framework.

2) Shared variables. Technically, they're not member variables, as they are shared (hence the name) amongst all instances of the class. If you're using these, you need to be careful how you access them. For example: you read the value of it, go do something else, then come back and read it again. It might have a different value the second time because another instance of your class updated it while you were busy.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[RebLazer]

Rogue and Chiph, thanks!

Chiph, are there no other downsides to member-variables other than the two points you mentioned? I don't remember being warned about either of those in school - there's no more basic reason - for a single-threaded execution?

Thanks!
Lazer

 

[DwaineC]

Okay, a step further. Should a class ALWAYS be self contained, that is, it should never rely on variables (or functions) outside of itself, even if there are other classes in the same app that share these variables and functions?

For instance, if I have a parsing function that two classes use, should I have that function private in both classes? That used to be considered poor programming.

I know, I know, I've left variables and gone into sharing functions, but I'm a 15-year experienced developer that has never had a class in my life relating to software development.