Singleton Pattern and Collections

[Robert W.]

At the beginning of my C# days (about 6 months ago) I learned about the
Singleton pattern and implemented for Reference data, such as the kind that
appears in an Options dialog box. My Singleton code looks like this:

public sealed class Reference
{
private static readonly Reference instance = new Reference();

// Make the default constructor private, so that nothing can directly
create it.
private Reference()
{
}

// public property that can only get the single instance of this class
public static Reference Data
{
get
{
return instance;
}
}
And then after that, but within the class, I add whatever properties I want.
This has served me very well.

But now I'd like to expand the use of the Singleton pattern to include
collections such as Users. My Users collection will be populated with a User
object, that itself will contain many properties such as "ID", "Name", etc.

I hit a roadblock though when I copied the above code to a new class I had
built for this purpose. The problem - I think - is that because the parent
class is sealed I can no longer access sub-classes like "User".

So I'm not sure how to proceed, other than removing the Singleton pattern.
This works but isn't really correct because now a developer could incorrectly
instantiate multiple versions when there really should be only one.

Any ideas how I could resolve this?

--
Robert W.
Vancouver, BC
www.mwtech.com

[Jon Skeet [C# MVP]]

Robert W. <Ro*****@discus sions.microsoft .com> wrote:

At the beginning of my C# days (about 6 months ago) I learned about the
Singleton pattern and implemented for Reference data, such as the kind that
appears in an Options dialog box. My Singleton code looks like this:
<snip>

That all seems to be correct.

And then after that, but within the class, I add whatever properties I want.
This has served me very well.

But now I'd like to expand the use of the Singleton pattern to include
collections such as Users. My Users collection will be populated with a User
object, that itself will contain many properties such as "ID", "Name", etc.

I hit a roadblock though when I copied the above code to a new class I had
built for this purpose. The problem - I think - is that because the parent
class is sealed I can no longer access sub-classes like "User".

So I'm not sure how to proceed, other than removing the Singleton pattern.
This works but isn't really correct because now a developer could incorrectly
instantiate multiple versions when there really should be only one.

Any ideas how I could resolve this?

I don't think I quite understand you. Are you saying there should only
be one collection of users? If so, create some class representing the
users, and make that a singleton. I don't see where class derivation
comes in...

You don't derive from a singleton class to create another singleton
class - singleton classes should always be sealed (and/or only have a
private constructor) as otherwise you end up with something which isn't
definitely a singleton.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bruce Wood]

I think I see Robert's problem. Maybe.

Robert: you can't create a generic "singleton reference class" and then
inherit from it to get different kinds of singletons. I doesn't work
that way.

You have to implement the Singleton pattern separately for each class
that you want to be a Singleton. These classes _can_ inherit from a
common parent, if in real-world terms it makes sense to do so, but the
parent wouldn't be a Singleton... it would likely be abstract, or
designed so that only its child classes could instantiate it.

Was that what you were asking?

[Robert W.]

Jon, Bruce,

Thank you both for responding. All of your insight helped me. What I was
doing wrong was including nested classes - such as "Users", "User",
"Devices", and "Device" inside the parent class. Once I turned the parent
class into a sealed Singleton class then I could no longer access the nested
classes.

Seems so simple now but I was completely stumped earlier today.

My dilemma now is that for another complex class I had built a completely
generic XML export function (the built-in one never worked) and a fairly
generic XML import function. Unfortunately they don't appear to work when
the parent class is a Singleton one. But I'm going to investigate if a
little tweaking would resolve it.

If that doesn't work then I can just forego the Singleton-nature and only
instantiate the parent class once. True this wouldn't be correct for
circulating the library to others, but since I'm in control of it myself it
might suffice.

I think I'm at that point in my project now where while I want to do
everything perfectly and generically, I also have to get the damned thing
done! :-)

--
Robert W.
Vancouver, BC
www.mwtech.com

"Bruce Wood" wrote:

I think I see Robert's problem. Maybe.

Robert: you can't create a generic "singleton reference class" and then
inherit from it to get different kinds of singletons. I doesn't work
that way.

You have to implement the Singleton pattern separately for each class
that you want to be a Singleton. These classes _can_ inherit from a
common parent, if in real-world terms it makes sense to do so, but the
parent wouldn't be a Singleton... it would likely be abstract, or
designed so that only its child classes could instantiate it.

Was that what you were asking?

[Jon Skeet [C# MVP]]

Robert W. <Ro*****@discus sions.microsoft .com> wrote:

Thank you both for responding. All of your insight helped me. What I was
doing wrong was including nested classes - such as "Users", "User",
"Devices", and "Device" inside the parent class. Once I turned the parent
class into a sealed Singleton class then I could no longer access the nested
classes.

You should be able to. Note that nested classes aren't derived from the
containing class. There shouldn't be any problem there.

Personally I wouldn't recommend using nested classes terribly often -
they're good for classes which are *only* used by their containing
classes (so they can be basically invisible to everything else) but
other than that, I'd stick to "one class per file".

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Helge Jensen]

Robert W. wrote:

At the beginning of my C# days (about 6 months ago) I learned about the
Singleton pattern and implemented for Reference data, such as the kind that
appears in an Options dialog box. My Singleton code looks like this:
That's a Singleton alright: a global variable holding an instance of a
class with only one instantiation. (As you may suspect, I'm not really
convinced singleton is a good design-pattern :)
But now I'd like to expand the use of the Singleton pattern to include
collections such as Users. My Users collection will be populated with a User
object, that itself will contain many properties such as "ID", "Name", etc.

Do you even *need* a UserCollection class? can't you use an ISet<User>
implementation? (which unfortunatly isn't available in .NET1.1 but can
be simply implemented using an IDictionary):

void f(ISet<User> users) {
foreach ( User u in users )
...;
}

Lets assume UserCollection have som functionality not in ISet<User>,
then and lets implement it:

public class UserCollection:
// you may implement ISet by composition or inheritance,
ISet<User>
{
public Add(User u) { ...something not in ISet implementation. .. }
... more things not in ISet implementation
}

now, I would just pass the UserCollection to operate on amongst functions:

void f(UserCollectio n users, ...) {
foreach ( User in users )
...
}

Why do you need to guarantee that only one instance of a UserCollection
ever exists? What value does it add to your program? what value does it
remove? (remember, it makes UserCollection a global variable and
prevents others from using the collection to represent Users).

If you believe passing the UserCollection around is too bothersome, you
can add:

public static UserCollection Global = new UserCollection( );

to class UserCollection. Now UserCollection. Global is effectively a
global variable (which is like a singleton, without guarantee that the
class is only intantiated once). This makes using code look like:

void f(...) {
foreach ( User in UserCollection. Global )
...
}

I have, (almost) never seen anywhere where the "only one instance of a
class" property yields value to a programs. the "global variable"
property is used often though... and people are even pround of it
because Singleton is a design pattern -- even though they haughtily
snorts at global variables as a rule!

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Ollie Riches]

Robert,

This site has a list of common design patterns and examples in .Net

http://www.dofactory.com/Patterns/Patterns.aspx

HTH

Ollie Riches

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Robert W. <Ro*****@discus sions.microsoft .com> wrote:

Thank you both for responding. All of your insight helped me. What I
was
doing wrong was including nested classes - such as "Users", "User",
"Devices", and "Device" inside the parent class. Once I turned the
parent
class into a sealed Singleton class then I could no longer access the
nested
classes.

You should be able to. Note that nested classes aren't derived from the
containing class. There shouldn't be any problem there.

Personally I wouldn't recommend using nested classes terribly often -
they're good for classes which are *only* used by their containing
classes (so they can be basically invisible to everything else) but
other than that, I'd stick to "one class per file".

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Søren Reinke]

"Helge Jensen" <he**********@s log.dk> wrote in message
news:O5******** ******@TK2MSFTN GP10.phx.gbl...

Robert W. wrote:

At the beginning of my C# days (about 6 months ago) I learned about the
Singleton pattern and implemented for Reference data, such as the kind
that appears in an Options dialog box. My Singleton code looks like
this:

That's a Singleton alright: a global variable holding an instance of a
class with only one instantiation. (As you may suspect, I'm not really
convinced singleton is a good design-pattern :)

What would you use instead ? If you wanted to be sure that there is only one
instance of a certain class ?

--
Best regards C.T.O. Søren Reinke
www.Xray-Mag.com/ - Your free diving magazin on the net. Download it in PDF
Aug-sept issue of X-RAY Magazine is ready to download:
EGYPT Finding Yolanda Wreck, Celebrate the Seas 2005

[Steve Walker]

In message <MP************ ************@ms news.microsoft. com>, Jon Skeet
<?@pobox.com.in valid> writes

Personally I wouldn't recommend using nested classes terribly often -
they're good for classes which are *only* used by their containing
classes (so they can be basically invisible to everything else) but
other than that, I'd stick to "one class per file".

Or which are only exposed via an interface visible elsewhere;
enumerators, for example.

--
Steve Walker

[Jon Skeet [C# MVP]]

Ollie Riches <ol**********@p honeanalyser.ne t> wrote:

Robert,

This site has a list of common design patterns and examples in .Net

http://www.dofactory.com/Patterns/Patterns.aspx

Unfortunately, the simple example given isn't threadsafe, and the more
complicated one uses double-checked locking (which doesn't work without
using a volatile field) and a Mutex rather than a Monitor (which is
needlessly expensive).

See http://www.pobox.com/~skeet/csharp/singleton.html for better
implementations .

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too