Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')

[Peter Donald <pe...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')

[Nicola Ken Barozzi <ni...@apache.org>]

Peter Donald wrote:
> 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. 

Which means that it's stateless in itself! :-)

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

Well, instead of Generator we have GeneratorService, but the difference 
is that Generator is used all over the place, while the service is 
just... well... the service :-)

Hey, this is good encapsulation!

>> 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!

Gee, Peter, thanks!
Now I think I'm getting excited ;-)
If others will agree (let's see) it could be that changing the way 
Cocoon works would really help Avalon, since it's a big example of how 
(not?) to use components (anyone here please correct me, it's my 
excitement that makes me say mad things ;-).

Could we generally say (I think so) that a good service should be:
1. stateless
2. encapsulate implementations, which doesn't only have to be an 
interface, but also (important) an interface that is not used in the 
framework, ie it must only be a... service ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>