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

[Robert W.]

Helge (and others),

You raise some interesting points. Let me go back to basics [of what I'm
trying to accomplish]. I have some data that I call "SysInfo" - User Info,
Supported Device (my app works with PPC apps), and Global Options. I also
have some data that I call "RefData" - Countries, Cities, Area Codes and
other such things.

In both cases, I need this data to be available to every module. Yes, I
suppose I could just pass these data objects around but I think that'll get
quite cumbersome.

I originally implemented the Singleton pattern because I thought (and I
think I had read) that it was the right solution for this kind of data:
- Global to everything
- Instantiated only once

While it's true that if I'm the only developer then I can just instantiate a
regular (non-Singleton) object and know not to instantiate it again, I
thought that Singleton was better if multiple developers got involved to
ensure that everyone was forced not to have multiple copies of what should be
just one set of data.

I very much welcome back any and all further feedback to this.

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

[Ollie Riches]

Thanks for tht Jon, Shot down in flames again :)

Ollie Riches

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

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

[Jon Skeet [C# MVP]]

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

Thanks for tht Jon, Shot down in flames again :)

Oh, I don't think that was very flamy. You should see me get going when
people claim that C# passes objects by references by default ;

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

[Robert W.]

Helge,

Can I ask you a quick follow-up to something you said?

Your Singleton alternative used this syntax:
public static UserCollection Global = new UserCollection( );

But then that means that everytime I want to reference anything I have to
prefix it with "UserCollection .Global." This just seems so redundant to me.

Is there a way to instantiate a global variable so that I could just
reference the various properties with this prefix: "UserCollection ." ?

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

"Helge Jensen" wrote:

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 <=-