[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avalon-dev
Subject:    Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for  'hints')
From:       Nicola Ken Barozzi <nicolaken () apache ! org>
Date:       2002-06-27 6:51:17
[Download RAW message or body]


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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

[prev in list] [next in list] [prev in thread] [next in thread]