Public Static Variables vs. the Singleton Class

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
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.
 
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.
 
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
 
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 said:
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
Click to expand...
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
 
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.
 
Back
Top