Public Static Variables vs. the Singleton Class

[Robert W.]

I've just been reading all about the Singleton class and understand how to
implement and use it but I cannot understand why one NEEDS to use it instead
of just declaring a class and implementing Public Static variables therein.

My usage revolves around global access to Reference Data. Some examples:
- Countries, States-Provinces, Cities, Area Codes
- Mobile Devices: Name, Description, Picture Filename

and other sorts of data that will rarely, if ever change. And since there
will always only need to be one copy of the data, going the Public Static
Variable route seems like the logical route.

Or am I missing something?

Robert W.
Vancouver, BC

[Bruce Wood]

The big drawbacks of static classes is that you can never treat them
like objects, and they don't participate in the class hierarchy and
thus don't support polymorphism.

The first drawback means that if you make a static class, you can never
pass it as a whole to any method, or store a reference to it in a
variable. Now, there are classes for which that's clearly not needed,
but it's a design consideration: "Will I never need to pass this thing
as an argument?"

The second drawback has more to do with future considerations. Would it
make any sense to have different versions of this thing for different
environments? Even if it stores no state, it may embody the
implementation of algorithms, and you may want to be able to "plug in"
different algorithms at a later date (Strategy pattern). Database
access layers are clear examples of things that look like they could be
static but, on further examination, shouldn't be, because a static
implementation precludes the support of multiple data sources, or at
least makes it more difficult.

If you're sure that you're never going to have to treat the thing as an
object (pass it to methods, etc), and you're sure that it will never
need to participate in the class hierarchy, then a static class is
fine.

One example you gave is a good one: if the class is just a glorified
constant-holder (countries, provinces, states, etc) then I see no need
to make a singleton of it.

[Robert W.]

Bruce,

Thanks for your feedback! As a newbie to C# and OOP I've still got a lot to
learn. You make some good points that I hadn't considered, especially the
part about passing the class to a method. I can already envisage writing a
method that would take the Reference Data object and iterate through it to
perform various tests for integrity, spelling, and such. While I could just
access the data in a non-OOP way, I'm trying to do things correctly from the
get go.

Thanks again!

Robert W.


"Bruce Wood" wrote:

The big drawbacks of static classes is that you can never treat them
like objects, and they don't participate in the class hierarchy and
thus don't support polymorphism.

The first drawback means that if you make a static class, you can never
pass it as a whole to any method, or store a reference to it in a
variable. Now, there are classes for which that's clearly not needed,
but it's a design consideration: "Will I never need to pass this thing
as an argument?"

The second drawback has more to do with future considerations. Would it
make any sense to have different versions of this thing for different
environments? Even if it stores no state, it may embody the
implementation of algorithms, and you may want to be able to "plug in"
different algorithms at a later date (Strategy pattern). Database
access layers are clear examples of things that look like they could be
static but, on further examination, shouldn't be, because a static
implementation precludes the support of multiple data sources, or at
least makes it more difficult.

If you're sure that you're never going to have to treat the thing as an
object (pass it to methods, etc), and you're sure that it will never
need to participate in the class hierarchy, then a static class is
fine.

One example you gave is a good one: if the class is just a glorified
constant-holder (countries, provinces, states, etc) then I see no need
to make a singleton of it.

[Robert W.]

Incidentally, could I ask one more question? After implementing the
Singleton class, I instantiated it (the single copy) like this:

static void Main()
{
Singleton test = Singleton.Instance;

Application.Run(new frmMain());
}
This all works fine but I then discovered that I could not access "test"
from anywhere else in the application. Instead I had to use
"Singleton.Instance." as a prefix before the property or variable.

Is this indeed correct that I'm not supposed to able to access "test" from
elsewhere in the application?

Robert


"Robert W." wrote:

Bruce,

Thanks for your feedback! As a newbie to C# and OOP I've still got a lot to
learn. You make some good points that I hadn't considered, especially the
part about passing the class to a method. I can already envisage writing a
method that would take the Reference Data object and iterate through it to
perform various tests for integrity, spelling, and such. While I could just
access the data in a non-OOP way, I'm trying to do things correctly from the
get go.

Thanks again!

Robert W.


"Bruce Wood" wrote:

The big drawbacks of static classes is that you can never treat them
like objects, and they don't participate in the class hierarchy and
thus don't support polymorphism.

The first drawback means that if you make a static class, you can never
pass it as a whole to any method, or store a reference to it in a
variable. Now, there are classes for which that's clearly not needed,
but it's a design consideration: "Will I never need to pass this thing
as an argument?"

The second drawback has more to do with future considerations. Would it
make any sense to have different versions of this thing for different
environments? Even if it stores no state, it may embody the
implementation of algorithms, and you may want to be able to "plug in"
different algorithms at a later date (Strategy pattern). Database
access layers are clear examples of things that look like they could be
static but, on further examination, shouldn't be, because a static
implementation precludes the support of multiple data sources, or at
least makes it more difficult.

If you're sure that you're never going to have to treat the thing as an
object (pass it to methods, etc), and you're sure that it will never
need to participate in the class hierarchy, then a static class is
fine.

One example you gave is a good one: if the class is just a glorified
constant-holder (countries, provinces, states, etc) then I see no need
to make a singleton of it.

[Brendan Green]

Of course not. The variable "test" only has a scope for the Main()
function.

Correct me if I'm wrong, but the whole point of a singleton is actually use
the "Singleton.Instance.<some_property_or_method> syntax in code.

"Robert W." <Ro*****@discussions.microsoft.com> wrote in message
news:A6**********************************@microsof t.com...

Incidentally, could I ask one more question? After implementing the
Singleton class, I instantiated it (the single copy) like this:

static void Main()
{
Singleton test = Singleton.Instance;

Application.Run(new frmMain());
}
This all works fine but I then discovered that I could not access "test"
from anywhere else in the application. Instead I had to use
"Singleton.Instance." as a prefix before the property or variable.

Is this indeed correct that I'm not supposed to able to access "test" from
elsewhere in the application?

Robert


"Robert W." wrote:

Bruce,

Thanks for your feedback! As a newbie to C# and OOP I've still got a lot
to
learn. You make some good points that I hadn't considered, especially
the
part about passing the class to a method. I can already envisage writing
a
method that would take the Reference Data object and iterate through it
to
perform various tests for integrity, spelling, and such. While I could
just
access the data in a non-OOP way, I'm trying to do things correctly from
the
get go.

Thanks again!

Robert W.


"Bruce Wood" wrote:

> The big drawbacks of static classes is that you can never treat them
> like objects, and they don't participate in the class hierarchy and
> thus don't support polymorphism.
>
> The first drawback means that if you make a static class, you can never
> pass it as a whole to any method, or store a reference to it in a
> variable. Now, there are classes for which that's clearly not needed,
> but it's a design consideration: "Will I never need to pass this thing
> as an argument?"
>
> The second drawback has more to do with future considerations. Would it
> make any sense to have different versions of this thing for different
> environments? Even if it stores no state, it may embody the
> implementation of algorithms, and you may want to be able to "plug in"
> different algorithms at a later date (Strategy pattern). Database
> access layers are clear examples of things that look like they could be
> static but, on further examination, shouldn't be, because a static
> implementation precludes the support of multiple data sources, or at
> least makes it more difficult.
>
> If you're sure that you're never going to have to treat the thing as an
> object (pass it to methods, etc), and you're sure that it will never
> need to participate in the class hierarchy, then a static class is
> fine.
>
> One example you gave is a good one: if the class is just a glorified
> constant-holder (countries, provinces, states, etc) then I see no need
> to make a singleton of it.
>
>

[John B]

Robert W. wrote:

Incidentally, could I ask one more question? After implementing the
Singleton class, I instantiated it (the single copy) like this:

static void Main()
{
Singleton test = Singleton.Instance;

Application.Run(new frmMain());
}
This all works fine but I then discovered that I could not access "test"
from anywhere else in the application. Instead I had to use
"Singleton.Instance." as a prefix before the property or variable.

Is this indeed correct that I'm not supposed to able to access "test" from
elsewhere in the application?

Robert

This is indeed correct.
You create a reference to your singleton instance object but that
reference will die once it passes out of scope. (as soon as Main finishes)

With singletons, you still need to declare a reference to your instance,
its just that these references will always point to the same instance.
(As compared to non-singleton which will point to different instances
(mostly))

You could access it via Singleton.Instance.<property/method/etc..>

HTH

JB

[Bruce Wood]

Yes. In fact, you don't need to instantiate the singleton in your Main
method. Just let the first access to Singleton.Instance create it. It
will be transparent to calling code.

After the first reference to Singleton.Instance, all future references
will just return the already-created object, so they cost hardly
anything.

And yes, it's the common idiom to see Singleton.Instance everywhere in
your code that you need the singleton, although it's also perfectly
reasonable to pop it into a local variable if you need to use it
repeatedly within a local bit of code.

[Bruce Wood]

Yes. In fact, you don't need to instantiate the singleton in your Main
method. Just let the first access to Singleton.Instance create it. It
will be transparent to calling code.

After the first reference to Singleton.Instance, all future references
will just return the already-created object, so they cost hardly
anything.

And yes, it's the common idiom to see Singleton.Instance everywhere in
your code that you need the singleton, although it's also perfectly
reasonable to pop it into a local variable if you need to use it
repeatedly within a local bit of code.