Really want to understand Singleton, and maybe static classes

  • Thread starter Thread starter BotRot
  • Start date Start date
B

BotRot

Hello Newsgroup,

Constructing a desktop application using C# 2008, .NET Framework 3.5 SP1, and
application files using Access 2007. Briefly the user interface, business layers
and data access-broker layers are constructed in C# (WinForms for the UI). The
application is multiple instancing (MDIParent interface), and the user can
construct application files (called project files) for their purposes.

If the application has a Singleton class with a (general) structure as such;

public sealed class ProjectStore
{
private static volatile ProjectStore instance = null;
private static readonly Object instance_lock = new Object;

// Constructors - Destructor

static ProjectStore()
{
lock(instance_lock)
{
if(instance == null) {instance = new ProjectStore();}
}
}

private ProjectStore() {// Maybe some stuff here}

// Method members a plenty here (non-static of course)

// Field members a plenty here (non-static of course), except for one

public static ProjectStore Instance
{
get {return instance;}
}

} // public sealed class ProjectStore

After reading quite a bit about Singleton classes, and what the above does, there
is one thing I do not understand. If my desktop application is multiple
instancing, is there one instance of my Singleton class for every application
instance? I.e. 3 application instances, hence 3 Singleton instances.

Or, is there only ever one instance of the Singleton for all instances of the
application? I.e. 3 application instances, "share" one Singleton instance

Also as a side note, there are quite a few (more like a lot) of discussions (on
many web pages) on whether the Instance member should be a field like;

public static TheClass Instance {get {return instance;}}

Or a function like;

public static TheClass GetInstance() {return instance;}

Apart from more typing for the field member, does it really matter?

Thank you for your consideration Newsgroup.

Thanks and regards,
- BotRot
 
BotRot said:
Hello Newsgroup,

Constructing a desktop application using C# 2008, .NET Framework 3.5 SP1,
and
application files using Access 2007. Briefly the user interface, business
layers
and data access-broker layers are constructed in C# (WinForms for the UI).
The
application is multiple instancing (MDIParent interface), and the user can
construct application files (called project files) for their purposes.

If the application has a Singleton class with a (general) structure as
such;

public sealed class ProjectStore
{
private static volatile ProjectStore instance = null;
private static readonly Object instance_lock = new Object;

// Constructors - Destructor

static ProjectStore()
{
lock(instance_lock)
{
if(instance == null) {instance = new ProjectStore();}
}
}

private ProjectStore() {// Maybe some stuff here}

// Method members a plenty here (non-static of course)

// Field members a plenty here (non-static of course), except for one

public static ProjectStore Instance
{
get {return instance;}
}

} // public sealed class ProjectStore

After reading quite a bit about Singleton classes, and what the above
does, there
is one thing I do not understand. If my desktop application is multiple
instancing, is there one instance of my Singleton class for every
application
instance? I.e. 3 application instances, hence 3 Singleton instances.
Click to expand...

Each running .NET application runs inside a process, which then conains an
application domain (AppDomain). An application's data is stored in the
memory allocated to that AppDomain and memory from one AppDomain cannot be
shared (directly) with memory in another AppDomain.

What this means is that if you have multiple application instances, then
each is running in its own AppDomain and you are getting an instance of your
class created for each of those application instances.
Or, is there only ever one instance of the Singleton for all instances of
the
application? I.e. 3 application instances, "share" one Singleton instance

Also as a side note, there are quite a few (more like a lot) of
discussions (on
many web pages) on whether the Instance member should be a field like;

public static TheClass Instance {get {return instance;}}

Or a function like;

public static TheClass GetInstance() {return instance;}

Apart from more typing for the field member, does it really matter?
Click to expand...

Just a bit on your terminology here. An "instance member" is a class member
(field, property, method, event) that is called through an instance of your
type, rather than the type itself. As such, instance members would NOT be
marked as static, which indicates that you want to be able to call the
member through the TYPE and not the instance.

What you've got here are static members that return an instance, so I might
call them "instancing members", rather than "instance members". But more to
your point. To stay true to OOP principles, properties exist mostly to
describe the "state" of a type and methods are for the type to exhibit
"behavior", so ask yourself: does your property code change the state of the
type? If it does, then a property is probably warranted. If all that your
code does is do a task, then a method is the way to go. If it is a mixture,
then its a tougher call, but generally if state is modified, then a property
should be used. From you basic code above, I'd say use the method.

-Scott
 
Thank you very much Scott M. It's good to implement something that not only
(just) works, but also understanding it's dynamics. Thanks again Scott M. very
well explained.

Thanks and regards,
- BotRot
 
Back
Top