Stephen McConnell wrote:
>
> I thought long and hard about the issues you have raised above. My
> decision to separate was driven on the grounds that an implementation
> can easily apply these patterns and default implementation. For example,
> in your case above .. it easy to define what you need by doing something
> like the following (ignoring exception management):
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object policy );
> boolean hasService( String role, Object policy );
> }
>
> public class DefaultServiceResolver extends DefaultServiceManager
> {
> Object lookup( String role, Object policy )
> {
> ((ServiceSelector)super.lookup( role )).select( policy );
> }
>
> boolean hasService( String role, Object policy )
> {
> ((ServiceSelector)super.lookup( role )).hasService( policy );
> }
> }
Right, this might be a better approach.
>>> interface ServicePool
>>> {
>>> Object checkout( Object token );
>>> Object checkout( Object token, Object criteria );
>>> void release( Object object );
>>> void releaseAll( Object token );
>>> }
>>>
>>You have nicely encapsulated the issue of "checkout/release", as it
>>clearly is a separate concern. However, it shouldn't be a concern of the
>>client. IMO, the client should be able to access different services in a
>>consistent way and not worry about whether certain instance is actually
>>pooled. This approach would require changes in the client code, when you
>>switch to a poolable service implementation.
>>
>
> I'm not convinced that it isn't a client concern. The contract between
> the client and the provider of the service is that it is the clients
> responsibility to check something back in. Ok, I understand that it is more
> convenient in a highly pooled environment for arbitrary release - but I
> don't find this a convincing argument in terms of the functionality of the
> framework. The reason why is that if you declare release on ServiceManager,
> you are implying that an implementation may support this (a generally
> speaking "may" is a very bad word).
I see your point and of course agree on the "may" argument, but I still
feel that the client shouldn't have to know whether the service instance
is pooled. What if there are many implementations for the same role, and
only some them are poolable. Shouldn't it be possible to switch the
implementation without changing the client code?
It would of course be possible to use 'dummy pools' for the thread-safe
services to avoid this, or some kind of a PoolAwareServiceManagerProxy,
but I'm not confident that it's the right approach.
(: A ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
