Antti Koivunen wrote:
> 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.
It isn't, and it results in very clumsy code.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
