Prev: Scala and problems with OOP
Next: Distributed Stock distribution system (assignment)
From: Ed Kirwan on 1 Nov 2007 02:42
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.
>

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.

--
..ed

www.EdmundKirwan.com - Home of the mathematical laws of encapsulation.
From: Daniel T. on 1 Nov 2007 09:17
Bilz <BrianGenisio(a)gmail.com> wrote:

> 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.)
From: Diego on 1 Nov 2007 12:29
On Nov 1, 11:17 am, "Daniel T." <danie...(a)earthlink.net> wrote:
> Bilz <BrianGeni...(a)gmail.com> wrote:
> > 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.)

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

From: Daniel Pitts on 1 Nov 2007 12:55
Bilz wrote:
> 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.
>
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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Peter Duniho on 1 Nov 2007 13:41
On 2007-11-01 09:29:57 -0700, Diego <jose.diego(a)gmail.com> said:

>> 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 :-(

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

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