static props and methods = global variables??

  • Thread starter Thread starter Daniel Billingsley
  • Start date Start date
D

Daniel Billingsley

I'd like to set (on launch) and then keep some AppDomain-wide variables.

Is there anything "bad" with doing something like this (dumb example), or is
there another more "standard" way of accomplishing it?

public class SomeInfo
{
private static _someText;

public static string Text
{
get { return _someText; }
}

public static void SelectText(int option)
{
if (int==1)
_someText = "one";
else
_someText = "something else";
}

}
 
The only question to ask is how often the items are going to be used. If
regularly, then keeping variables in memory is not a bad thing. I routinely
use a singleton for application settings. The singleton stores all sorts of
vars, which makes a convenient object that can be used again and again. As a
singleton, it gets created the first time it is requested, so I do not have
an app ramp up time, per se.

Static variables/properties are a good means of holding config type
information, if that is what you are asking. Static methods are great for
helper methods that do not require individual state.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
 
Daniel Billingsley said:
I'd like to set (on launch) and then keep some AppDomain-wide variables.

Is there anything "bad" with doing something like this (dumb example), or is
there another more "standard" way of accomplishing it?
Click to expand...

Another question is modification. If the variables will never be modified
after initialization, then there's no problem. But if they can be modified,
then all access to the variables should be synchronized in case of access
from multiple threads.
 
Thanks guys. Yes it's application setting kind of stuff that will be set at
the launch of the app. User gets to select between two databases, for
example.

A singleton seems like a different thing in that there is an instance of it
held somewhere. Where? I wanted my class to be effectively completely
static so it acted like global variables where they're just available
directly from anywhere within my app.

John, since the Select method to set the static private variable would be
done at the very very start of the app and then it would be immutable from
then on I wouldn't really need to worry about thread safety, would I. There
will still be one copy per app domain, right?
 
Daniel Billingsley said:
Thanks guys. Yes it's application setting kind of stuff that will be set at
the launch of the app. User gets to select between two databases, for
example.

A singleton seems like a different thing in that there is an instance of it
held somewhere. Where? I wanted my class to be effectively completely
static so it acted like global variables where they're just available
directly from anywhere within my app.
Click to expand...

The instance of it is held in a static variable, so it's AppDomain
wide, just alike all other static variables.
John, since the Select method to set the static private variable would be
done at the very very start of the app and then it would be immutable from
then on I wouldn't really need to worry about thread safety, would I. There
will still be one copy per app domain, right?
Click to expand...

Yes.
 
Jon Skeet said:
The instance of it is held in a static variable, so it's AppDomain
wide, just alike all other static variables.
Click to expand...

Oh yeah of course. Do you see any effective difference between a singleton
and the code I posted? I would think a singleton would be more called for
in the case of a relatively more volatile class for which there should still
only be on instance, but wouldn't really matter in my pretty immutable
class. The singleton would use a tad more memory, but nothing really
significant. Yes, no, maybe so?
Yes.
Click to expand...

Yes there'd only be one copy and since I create it early (say in the load of
the MDI parent) I really don't need to worry about threads - or yes I do
need to take threading into consideration even at that point? :)
 
Daniel Billingsley said:
Oh yeah of course. Do you see any effective difference between a singleton
and the code I posted? I would think a singleton would be more called for
in the case of a relatively more volatile class for which there should still
only be on instance, but wouldn't really matter in my pretty immutable
class. The singleton would use a tad more memory, but nothing really
significant. Yes, no, maybe so?
Click to expand...

Well, the singleton instance can also be passed to other things as a
parameter, should it need to be - it doesn't often happen, but it can
occasionally.
Yes there'd only be one copy and since I create it early (say in the load of
the MDI parent) I really don't need to worry about threads - or yes I do
need to take threading into consideration even at that point? :)
Click to expand...

Shouldn't need to.
 
Jon Skeet said:
Well, the singleton instance can also be passed to other things as a
parameter, should it need to be - it doesn't often happen, but it can
occasionally.
Click to expand...

Moving away from the specific case here, could you explain how that would be
useful? Passing it as a parameter would be a waste of code (at least)
wouldn't it, since the called method could just get it itself? It's not
like the calling code could indicate "use this instance" since it is a
singleton.
 
Normally, if the class is to be a singleton, I create a Shared (static)
GetInstance() function that I need to call in any routine that needs
access to the class. This way there is no passing of the class instance
around. Just call GetInstance() and the parameter that is needed.

HTH

David
 
Daniel Billingsley said:
Moving away from the specific case here, could you explain how that would be
useful? Passing it as a parameter would be a waste of code (at least)
wouldn't it, since the called method could just get it itself? It's not
like the calling code could indicate "use this instance" since it is a
singleton.
Click to expand...

Don't forget that you sometimes pass parameters to code you don't have
control over yourself - or which shouldn't need to know what it's going
to be dealing with. For instance, your singleton could implement
various interfaces - you might even serialize it, and deserialize it to
create it at the start of the next run. Or you might pass it into
something which examines it properties with reflection. Or it might
even derive from a base class which you use elsewhere and which might
have multiple instances (or have other derived classes).

Just examples of what *might* happen - as I said, it doesn't happen
often, but it *can* happen.

Another thing which building the object as a singleton helps with is
refactoring if you later decide to remove the singelton aspect of it:
changing every static method call can be a lot harder than just
changing every location where the singleton is originally retrieved.
That's another rare occurrence, but it can happen.
 
Ok. Good points as usual Jon. Thanks.

Jon Skeet said:
Don't forget that you sometimes pass parameters to code you don't have
control over yourself - or which shouldn't need to know what it's going
to be dealing with. For instance, your singleton could implement
various interfaces - you might even serialize it, and deserialize it to
create it at the start of the next run. Or you might pass it into
something which examines it properties with reflection. Or it might
even derive from a base class which you use elsewhere and which might
have multiple instances (or have other derived classes).

Just examples of what *might* happen - as I said, it doesn't happen
often, but it *can* happen.

Another thing which building the object as a singleton helps with is
refactoring if you later decide to remove the singelton aspect of it:
changing every static method call can be a lot harder than just
changing every location where the singleton is originally retrieved.
That's another rare occurrence, but it can happen.
Click to expand...
 
Cowboy (Gregory A. Beamer) said:
The only question to ask is how often the items are going to be used. If
Click to expand...

I think it's also worth considering lifetime as well. A global variable can
have an unclear or badly defined lifetime, and that can cause you problems.
regularly, then keeping variables in memory is not a bad thing. I routinely
use a singleton for application settings. The singleton stores all sorts
Click to expand...
of

As an example, do these app settings ever get written as well as read? If
not then fine, but if so you have a lifetime issue -- when do they get
written? As another example, what if the application settings need to change
midway through execution?

Many types of static/global data could really be considered a cache of some
sort (as in the app config example), and the golden rule there is "caching
implies policy" -- if you can't tell me the policy, you're likely to have
problems.

(And to anticipate Mr. Beamer's reply, the policy there is probably
'read-only; lifetime must extend at least until last access; small data vs.
relatively slow access to original data makes it worth it').
 
Stu Smith said:
in message news:%[email protected]...

I think it's also worth considering lifetime as well. A global variable can
have an unclear or badly defined lifetime, and that can cause you
Click to expand...
problems.

In general, I try to use static items for application level processes and
kill them on the application end, so I neglected the lifetime issue. Good
catch!
of

As an example, do these app settings ever get written as well as read? If
not then fine, but if so you have a lifetime issue -- when do they get
written? As another example, what if the application settings need to change
midway through execution?
Click to expand...

Generally, for config objects, you are not changing them in the midst of the
application. Regardless, I am very fond of explicit coding, so I destroy the
objects when the application unloads. The only time this is not caught is
when the server dies, but that is not an issue as the memory is killed when
the server is dead.
Many types of static/global data could really be considered a cache of some
sort (as in the app config example), and the golden rule there is "caching
implies policy" -- if you can't tell me the policy, you're likely to have
problems.

(And to anticipate Mr. Beamer's reply, the policy there is probably
'read-only; lifetime must extend at least until last access; small data vs.
relatively slow access to original data makes it worth it').
Click to expand...

Certainly, there is a trade off with any type of programming. For example,
one oft errs on the side of performance only, which is a major mistake, as
maintainability costs businesses more than performance in most scenarios.

In most cases, I would be wary of static variables and properties unless
there is a reason for them. There are so many ways to cache data in the .NET
Framework that fit most scenarios, so coding your own, if there is an
acceptable caching method, is unwise.

Static helper methods are a different issue.

The unfortunate thing about open forums is we often have to speak in
generalities due to our own time constraints. I agree with the points you
make.
 
Back
Top