On Wednesday 11 February 2004 21:32, Joerg Heinicke wrote:
> What's the problem of a generic interface? Isn't it an issue of the
> implementation to be more specific?
No, the issue at hand is that IF the client-component is written against a
"observed behaviour" of a particular container, re-use and interchangeable
compents between containers suffers.
> And how should it be done instead?
Since the "selection process" is tied to the component (i.e. it knows how it
wants to provide "hints"), the Avalon community back then came to the
conclusion that the generic selector pattern is no good, and should be done
by component specific selectors.
Now, since there are N ways of implementing this, it is little bit up to you
to take a step back and say; "What do I really need?" and not looking at what
is provided in "the old days".
It could be as simple as;
public interface MyHeroSelector
{
MyHero get( String hint )
throws ServiceException;
}
public class MyHeroSelectorImpl
implements MyHeroSelector, Serviceable
{
private ServiceManager m_Manager;
/**
* avalon.dependency type="MyHero" key="batman"
* avalon.dependency type="MyHero" key="mickey-mouse"
*/
public void service( ServiceManager man )
{
m_Manager = man;
}
public MyHero get( String hint )
throws ServiceException
{
if( hint != null && hint.equals( "superhero" ) )
return (MyHero) m_Manager.lookup( "batman" );
return (MyHero) m_Manager.lookup( "mickey-mouse" );
}
}
and in the user code, do the lookup on the MyHeroSelector, and explicitly call
the get() method.
But there might be endless variations on what can happen, hence the decision
to deprecate and discourage the use of service selectors.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
