Stephen McConnell wrote:
> Paulo:
>
> I agree on the efficiency point, .. however the interface is
> loosing something in terms of implicit clarity and potential for
> consistent usage (it's starting to look more like hashtable
> get/indexof/remove). I would prefer to move further towards an
> interface that (a) expresses notions of service provision/
> decommissioning more concretely and explicitly (i.e. closer to
> yesterday), but (b) enhanced to address input from yourself,
> Antti and Sylvain during the evening that touched on the
> parallelism between lookup and hasXxxx. Thinking about the
> parallelism issue for the last few hours as a result of those
> comments leads me to the conclusion that non-parallel
> lookup/hasXxxx effectively implies potentially unwarranted
> implementation restrictions. A resolution could be the addition
> of a supplementary hasXxxx method as shown below.
>
> interface ServiceManager
> {
> Object lookup( final String role );
> Object lookup( final String role, Map policy );
>
> boolean hasService( final String role );
> boolean hasService( final String role, Map policy ); <-- addition ?
>
> void release( Object key );
> }
>
> The addition of hasXxxxx( key, policy ) ensures that your not going
> on a blind date. The boolean result of the operation should
> semantically be quite clear in that TRUE hasXxxxx response should
> indicate that within reasonable operating conditions, the lookup
> operation will not fail. It is then up to implementations to resolve
> decisions concerning ability to honour a service availability
> commitment (potentially in the context supplied policy).
>
> What do you think?
Sounds good.
--
"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]>
