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>shocking</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

 

[Roedy Green]

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

You need some sort of factory to create your service provider. Perhaps
it can cache them, and reuse an existing provider if its set of
configurations have already been used before.

You create a key class that contains the various distinguishing
initialisation parameters, then a hashCode that xors the various
fields. Then use this key class to create index into your HashMap
cache of pre-built providers.

 

[Bilz]

You need some sort of factory to create your service provider. Perhaps
it can cache them, and reuse an existing provider if its set of
configurations have already been used before.

You create a key class that contains the various distinguishing
initialisation parameters, then a hashCode that xors the various
fields. Then use this key class to create index into your HashMap
cache of pre-built providers.

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? This is what I am trying to avoid...
though I can't think of a way how.

 

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

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>shocking</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).

I would prefer solution #1 over #2. Much more flexible.

As a long time solution that seems obvious.

For a dirty hack: if the two instances of the software are actually
running in different threads, then you could register each thread to
a given instance of the software and have the singleton create
based on thread.

Arne

 

[instcode]

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>shocking</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

Hix, I encountered the same problem with you but I haven't found out
any elegant solution yet. My application is a rich client applet, it's
required to allow more than one concurrent users run multiple applets
in the same browser window!! You've known, within a Firefox/IE window,
the applet class loader runs on the same JVM and make the singleton to
be death!! In my case, I prefer the #1 to #2 because I can use the
username as the lookup-key and it quite simple ...

Now I talk about another solution that would be feasible in your case,
I don't know . If your application is allowed to create a new
classloader (my case, require a signed applet, hix...), you can use
that classloader to load all your classes in another "working-space",
and the singleton might work independently.

Hix, after this circumstance, I swore not to use singleton if it
carries my data, it's awful!!

 

[Ed Kirwan]

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>shocking</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.

FWIW, that's what I used:
http://www.edmundkirwan.com/servlet/fractal/cs1/code/package47.html#doPost

In that method, an access is createed each time the user clicks a button on
a web page, and that access is passed to every object in the system that
needs it.

There is no magic solution.

Yes, it feels awkward.

Yes, it feels as though there, "Should," be a better solution.

There isn't.

 

[Daniel T.]

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>shocking</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.

Just out of curiosity, which method would you have chosen if someone had
told you up front "no globals"? (After all, a singleton is just a global
with a pretty wrapper.)

 

[Diego]

Just out of curiosity, which method would you have chosen if someone had
told you up front "no globals"? (After all, a singleton is just a global
with a pretty wrapper.)

if singletons are globals, then "no globals" is a mere illusion :-(

 

[Daniel Pitts]

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? This is what I am trying to avoid...
though I can't think of a way how.

Even if you pass a key all the way down, you'd be better off passing the
actual object all the way down, then you eliminate the need to do a map
lookup.

If you're using Java, and the partition aligns nicely with threads, you
can use ThreadLocal variables...

Also, look into the Dependency Injection pattern, as well as other forms
of Inversion of Control.

You don't have to pass it into every constructor, but just make sure
that your object relationships have everything you need to get the
configuration you care about.

As a matter of fact, you should probably have your configuration object
instantiate most of the objects (think of it as a factory), and have it
connect them to each other.

 

[Peter Duniho]

if singletons are globals, then "no globals" is a mere illusion :-(

There's no official definition of a "global", so it's more a matter of
semantics than of illusion.

In the strictest sense, a singleton or other static member is not a
global at all. In a relaxed sense, any static member of any top-level
class is a global, and in an even more relaxed sense any static member
of any class is a global.

Personally, I prefer the strictest definition of "global": an
identifier that is accessible globally, without any decoration at all.
This correlates reasonably well to the usual use of the word "global"
in programming languages.

If you would consider a local static variable in a C++ function to be a
"global", then I'd agree that singletons and other static things in C#
would be "globals" as well. Otherwise, I'd say it's a bit of a stretch
to claim that.

Pete

 

[Lew]

if singletons are globals, then "no globals" is a mere illusion :-(

I don't know what that means. Static variables, singletons - both are globals
in some sense.

The singleton pattern isn't the magic bullet that so many people think.

 

[Daniel T.]

There's no official definition of a "global", so it's more a matter
of semantics than of illusion.

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.

And the question still stands to the OP, if you had known from the
outset of the new feature, how would you have implemented it?

 

[Peter Duniho]

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]

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.

 

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

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

 

[Daniel T.]

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.

Fine, ignore the reference to globals. The question to the OP still
stands. I'm trying to help the OP solve his problem. In order to do so,
I would like to know how he would have solved it if he had known of the
design up front instead of it being a design change.

 

[AndyW]

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>shocking</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.