At 08:21 AM 6/27/2002 +0200, you wrote:
>>>This would mean (Cocoon example) that the cm would not give you a
>>>Transformer or a Generator, but a service that manages them.
>>Depends on interface of Generator. If it is a resource then yes, if it is
>>a service then no. It sounds like Generator has been made a resource
>>(really bad move IMHO) and thus you do need a GeneratorManager.
>>Personally I would have made it a service.
>
>Hmmm... Isn't the GeneratorManager the service for the Generator?
>I guess not, since I'm asking objects (ie Generators) to it, not making it
>generate(), right?
yep
>Making it a service could mean setting the Generator type and calling
>generate() on the service, so I don't even have to get an object from it,
>which is worse.
Thats one way of doing it. However I would tend to pass in the type to the
method. Now the callers of GeneratorService don't even have to know that
there is such an interface as Generator and it becomes an implementation
detail you are free to change in future. Kool huh.
>I have understood some time age (though I'm not so good a doing yet) that
>to encapsulate well and reduce roundtripping madness you should always
>call methods on objects, not request other objects.
>Using a GeneratorService would make this possible, right?
Largely and the clients would not need to know whether the Generator is
pooled, un-pooled, clustered, distributed or anything else. All they know
is that they call method X with parameters Y to get a service. Zero
resource management on their side. Yea yea yea!
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
