Static Class

[Jon Vaughan]

I have a piece of code that I want to run on a Pocket Pc, I have written a
data class that will store the small amount of data that is required for the
program. As this class will be used via a few forms in the program, what the
best way to setup this class - Static ? and if so where do I enter the setup
for the initial fetch, as at the moment its in the constructor, i'm right in
thinking there is no constructor in a static class.

Thanks

 

[Hitesh Ramchandani]

Static class cannot have a constructor, but it is still possible to declare
a static constructor to initialise default values to the static data. This
static constructor is called automatically before any static members are
referenced.

So you can create a static class with static members and if needed a static
constructor as well, and store the data in the static members.

-H

 

[Jon Vaughan]

Hitesh,

Does using a static class sound the right use for what im looking for ?

 

[Shawn Wildermuth (C# MVP)]

Hello Jon,

There has been a long and entertaining discussion of static classes on the
Windows OffTopic mailing list recently. After hearing lots of opinions (some
of which I actually agree with), I think what you really want is a singleton:

public SomeSingleton
{
// Private to prevent public construction
private SomeSingleton()
{
// Your Init Logic
}

private SomeSingleton _theInstance = null;

public SomeSingleton TheInstance
{
get
{
if (_theInstance == null)
{
_theInstance = new SomeSingleton();
}

return _theInstance;
}
}
}

This defers the creation of hte singleton until its first use. I like pure
static classes for stateless code, but since you have start-up data, I think
the singleton pattern is simpler in the long run (as the instance of the
class can hold all its own data, but you're only supporting a single instance).

HTH

Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

 

[Hitesh Ramchandani]

Jon,

It would depend on what type of identity(data) would the static class hold
with reference to the application.
If the actual data values of the static class would be used by the forms
then i dont see anything wrong with having a static class with static
members.

i am not familiar with the usage of pocketpc databases to store data; which
you may want to consider if the data is large.

-H

 

[Jon Skeet [C# MVP]]

There has been a long and entertaining discussion of static classes on the
Windows OffTopic mailing list recently. After hearing lots of opinions (some
of which I actually agree with), I think what you really want is a singleton:

public SomeSingleton
{
// Private to prevent public construction
private SomeSingleton()
{
// Your Init Logic
}

private SomeSingleton _theInstance = null;

public SomeSingleton TheInstance
{
get
{
if (_theInstance == null)
{
_theInstance = new SomeSingleton();
}

return _theInstance;
}
}
}

That's an overly complicated *and* non-threadsafe implementation

See http://www.pobox.com/~skeet/csharp/singleton.html for other
options.

 

[Shawn Wildermuth (C# MVP)]

Hello Jon Skeet [C# MVP],

Of course its not threadsafe! hehe...

THere ya go for a class written in a post. I like some of your approaches
on that website, but the inner class static class stuff is more complicated
than this is. I was going with the classic GOF singleton pattern idea.
You would need to make all calls threadsafe, I was hoping that this was a
starting point...not a completed piece of code...

The (hopefully) sallient idea here is that the singleton pattern makes more
sense for a stateful object. And to Jon's point...you *have* to make it
threadsafe and that is entails more than just making the creation of the
object be threadsafe, but access to the data needs to be threadsafe as well.

HTH

Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

 

[Jon Skeet [C# MVP]]

Hello Jon Skeet [C# MVP],

Of course its not threadsafe! hehe...

THere ya go for a class written in a post. I like some of your approaches
on that website, but the inner class static class stuff is more complicated
than this is.

Absolutely - which is why I'd only go for that in extreme cases.

I was going with the classic GOF singleton pattern idea.

Yeah, but in the GOF days threading wasn't quite so common...

You would need to make all calls threadsafe, I was hoping that this was a
starting point...not a completed piece of code...

Unfortunately people tend to cut and paste code straight out of posts

The (hopefully) sallient idea here is that the singleton pattern makes more
sense for a stateful object. And to Jon's point...you *have* to make it
threadsafe and that is entails more than just making the creation of the
object be threadsafe, but access to the data needs to be threadsafe as well.

Indeed. Singletons *tend* not to have much mutable data associated with
them IME, but if they do, you do indeed need to be careful.