Looking for a pattern

[Bilz]

Hello,

I am looking for a good pattern. I have a rather large software app
that makes use of a service manager for its many services...
configuration, colors, data lookup, units, etc. Up until now the
service manager has been a singleton and anyone who wants access to a
service just asks the singleton.

Now we have a new requirement... run multiple instances of the
software in the same application space with different configurations.
<sarcasm>shocki ng</sarcasm>

So, now I need to think about a good design pattern to help me here.
I can only come up with two awkward options:

1. Pass a service manager key to every constructor of every class that
needs access to the service manager. The class can go to a singleton
to ask for the instance of the service manager by key. This is
awkward and I don't like it.

2. Create an interface for getting a service, and have every object in
the object tree implement the interface. Pass a "parent" object
reference to the "child" and implement the interfaces so they climb
the tree all the way to the root node to get an instance of the
service manager stored in the root node. This is better, but still
awkward.

Is there a better design pattern out there to do what I need? I am
using .NET C#, though it shouldn't matter too much (unless .NET
already has a service I can leverage).

Thanks,
Brian

[Peter Duniho]

On 2007-11-01 13:20:33 -0700, "Daniel T." <da******@earth link.netsaid:

The whole point of a singleton is to "Ensure a class only has one
instance, <i>and provide a global point of access to it.</i>" (GoF pg.
127 emphasis added.) Global access, means global IMO.

I understand that "singleton" has a perhaps a very specific meaning in
the particular book in which (it seems) this whole idea of "design
patterns" was first suggested.

However, I see nothing to prevent someone from implementing a singleton
that is not accessible globally. And I would still call it a singleton.

Furthermore, in C# any singleton itself is not accessible globally; you
need to start with the namespace, and then a particular class name, at
a minimum.

I don't see the point in raising the question of whether globals can
exist in C# anyway, but assuming the question has been raised it seems
silly to insist that the singleton pattern is somehow related to the
question. You have to define "global" first before you can say whether
the singleton pattern exists if and only if globals do, and once you've
defined "global", you don't need to look at the singleton pattern to
decide whether they exist in a language or not.

Pete

[Roedy Green]

On Thu, 01 Nov 2007 01:45:54 -0000, Bilz <Br**********@g mail.com>
wrote, quoted or indirectly quoted someone who said :

>Ok, that is fine... but how does all of the classes get the key? Do
you pass them in to every constructor, and keep track of the key all
the way down the object graph?

you pass your parameters to the factory. It composes the key to see if
it built a suitable config object before, if not it calls the
constructor with the parms and adds it to the pool.

Imagine how you might cache Font bitmaps using family, size, style as
the key.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Peter Duniho wrote:

On 2007-11-01 13:20:33 -0700, "Daniel T." <da******@earth link.netsaid:

>The whole point of a singleton is to "Ensure a class only has one
instance, <i>and provide a global point of access to it.</i>" (GoF pg.
127 emphasis added.) Global access, means global IMO.

I understand that "singleton" has a perhaps a very specific meaning in
the particular book in which (it seems) this whole idea of "design
patterns" was first suggested.

They defined it and gave it the name.

It is a well known source.

It would be pure obfuscation to use the same well known term about
something different.

Furthermore, in C# any singleton itself is not accessible globally; you
need to start with the namespace, and then a particular class name, at a
minimum.

That has nothing to do with accessibility.

Arne

[AndyW]

On Wed, 31 Oct 2007 19:30:23 -0000, Bilz <Br**********@g mail.com>
wrote:

>Hello,

I am looking for a good pattern. I have a rather large software app
that makes use of a service manager for its many services...
configuratio n, colors, data lookup, units, etc. Up until now the
service manager has been a singleton and anyone who wants access to a
service just asks the singleton.

Now we have a new requirement... run multiple instances of the
software in the same application space with different configurations.
<sarcasm>shock ing</sarcasm>

So, now I need to think about a good design pattern to help me here.
I can only come up with two awkward options:

1. Pass a service manager key to every constructor of every class that
needs access to the service manager. The class can go to a singleton
to ask for the instance of the service manager by key. This is
awkward and I don't like it.

2. Create an interface for getting a service, and have every object in
the object tree implement the interface. Pass a "parent" object
reference to the "child" and implement the interfaces so they climb
the tree all the way to the root node to get an instance of the
service manager stored in the root node. This is better, but still
awkward.

Is there a better design pattern out there to do what I need? I am
using .NET C#, though it shouldn't matter too much (unless .NET
already has a service I can leverage).

Thanks,
Brian

Sounds like you just need to implement versioning in a WCF
application.
----------------
AndyW,
Mercenary Software Developer