Prev: Scala and problems with OOP
Next: Distributed Stock distribution system (assignment)
From: Bilz on 31 Oct 2007 15:30
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

From: Roedy Green on 31 Oct 2007 16:32
On Wed, 31 Oct 2007 19:30:23 -0000, Bilz <BrianGenisio(a)gmail.com>
wrote, quoted or indirectly quoted someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
From: Bilz on 31 Oct 2007 21:45
On Oct 31, 4:32 pm, Roedy Green <see_webs...(a)mindprod.com.invalid>
wrote:
> On Wed, 31 Oct 2007 19:30:23 -0000, Bilz <BrianGeni...(a)gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
> >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.
> --
> Roedy Green Canadian Mind Products
> The Java Glossaryhttp://mindprod.com

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.

From: Arne Vajhøj on 31 Oct 2007 22:33
Bilz 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...
> 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
From: instcode on 1 Nov 2007 00:42
On Nov 1, 2:30 am, Bilz <BrianGeni...(a)gmail.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...
> 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!! :-)

 |  Next  |  Last
Pages: 1 2 3 4
Prev: Scala and problems with OOP
Next: Distributed Stock distribution system (assignment)