Hi Steve, answer inline: > -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 14, 2002 5:59 AM > > > 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).
Sorry Steve, I did not express my ideas that well on that post, but maybe I did it a bit better on this one: http://www.mail-archive.com/[email protected]/msg06057.html On the above linked post I give the example of a ClassicCM class with a similar interface to the one you show here for the ServiceManager (although with a "token" for easy component release) that wraps a ComponentManager with an Object key. I think that the ComponentManager and the ServiceManager have more in common as a problem than they have different. And that is my main concern - not the implementation efficiency (I was not clear about this before). IMO the ComponentManager and the ServiceManager are just specializations of an ObjectManager (just to take the Component and Service terms out of the way) that manages objects with a LifeStyle (and a LifeCycle). Of course that there can be several possible types of LifeStyles, but an ObjectManager would specialize on knowing them and managing such objects on an optimal way. On top of that you could then build a specialization called ComponentManager or ServiceManager to manage the specific types of objects-with-a-LifeStyle that you call Components or Services and for which you use a specific "indexing" strategy (e.g.: role + parameters). You could even manage other objects-with-a-LifeStyle... like ScriptingVariables and strange things like that. So, what I want to say is that I consider the problem of managing objects-with-a-LifeStyle important enough to deserve a separate layer. Then you could have ObjectManagerImplementation | ObjectManager (interface) | ComponentManagerWrapper | ComponentManager (interface) Meaning that you could have a specific implementation of an ObjectManager interface which, using a ComponentManager wrapper is exposed as a ComponentManager. The wrapper being something like the ClassicCM class in http://www.mail-archive.com/[email protected]/msg06057.html This means that you could easily replace the underlying object management implementation with ease and even reuse it for a ServiceManager like: ObjectManagerImplementation | ObjectManager (interface) | ServiceManagerWrapper | ServiceManager (interface) > 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), I think the above matches your concerns. > 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). I agree, of course. > What do you think? > > Cheers, Steve. Have fun, Paulo Gaspar > > > > ...but Map does allow potentially more efficient implementations. > > > > For efficiency: > > > > interface ServiceManager > > { > > Object lookup( Object key ); > > boolean hasService( Object key ); > > void release( Object key ); > > } > > > > IMO this provides the most efficient basic implementation and > > maximum flexibility. > > > > Than you can specialize according to your needs. > > > > > > Have fun, > > Paulo Gaspar > > .......... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
