Steve,
Stephen McConnell wrote:
>>>
>>> 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.
>>
>
> I'll take that as meaning "Right, that IS a better approach." and
> proceed on the grounds that we can look at this once the core stuff is
> settled.
After thinking about it, I'm no longer sure. For the ServiceResolver to
be of real use, we would also have to define the following interface:
interface ServiceResolvable
{
setServiceResolver( ServiceResolver resolver );
}
The implications of this are actually even worse than the additional
interface. Be it in the Framework or Excalibur, users would naturally
choose the one they like best (find more convenient). This would lead to
a bunch of components that are in a way incompatible. Pushing two
alternatives for performing the same task is not a good thing.
>>>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 ([and] 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.
>>
>
> This is a good argument. But there are implications on interface clarity
> and consequence of the framework implementations that I don't like. If
> you declare an interface which is agnostic relative to the provisioning
> policy, then you force modification of the lookup operation to include
> a token argument (because an pooled implementation needs the token). This
> compremises the interface for ServiceManager beyond the "comfort zone".
>
>
>>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?
>>
>
> I agree completely with the scenario objective. I don't think the
> consequences of the convenience support are justified. An implementation
> of ServiceManger that supported "release" on the grounds that it is
> auto-magically handling recycled components would require something like
> a foralll embedded pools and selectors - release this object if you have
> a reference to it. Given a choice between forcing clients to take
> responsibility for knowing for service procurement source type, as
> opposed to generic simplification at the framework level, in this
> particular case my preference is to push this burden onto the client for
> the sake of framework integrity.
I agree with you that there shouldn't be any 'ifs' in the framework
interfaces, and normally I would be against adding anything that
compromises the 'framework integrity', as you put it. However, the
inclusion of release() would be straightforward for the clients and make
the use of the framework more consistent (i.e. always release).
Considering the implications of adding ServiceResolver, I don't really
see it as a viable alternative for this. But I'm still not sure about
the best approach, so I'd like to hear about any real (practical)
drawbacks of including release() (see my previous suggestions).
(: A ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
