On Saturday 17 January 2004 15:21, Leo Simons wrote:
I Am Pro-ROLE ------------- I have used and written dozens of components that define ROLE, and it has always worked perfectly for me.
The main useful thing about ROLE for me is that you define it in the work interface, and even in deep inheritance it is always clear (because its 'lightweight forced') what exactly constitutes the work interface.
Could you elaborate on this a bit?? I have probably asked this before, and I have yet to see the light.
Well, the point I made above is:
public interface WorkInterface
{
public final static String ROLE = WorkInterface.getClass().getName(); doStuff();
}
public interface SuperWorkInterface extends WorkInterface
{
// error: public final static String ROLE =
// WorkInterface.getClass().getName(); doMoreStuff();
}
public class MyComp implements SuperWorkInterface
{
// ...
// compiler error: public final static String ROLE =
// WorkInterface.getClass().getName();
}public void service( ServiceManager sm )
{
WorkInterface wi = (WorkInterface)sm.lookup( WorkInterface.ROLE );
// error: SuperWorkInterface wi =
// sm.lookup( SuperWorkInterface.ROLE );
// error: SuperWorkInterface wi =
// sm.lookup( MyComp.ROLE );
// no error:
WorkInterface wi = (WorkInterface)sm.lookup(
WorkInterface.ROLE );
if( !(wi instanceof SuperWorkInterface) )
log.warn("Degraded service!");
}you might say using ROLE discourages sub-work-interfaces, or at least somewhat 'forces' clients to be aware of the hierarchy (everyone can ignore it, but its there). With a pure getClass().getName(), this is not the case:
public void service( ServiceManager sm )
{
// more typing!:
WorkInterface wi = (WorkInterface)sm.lookup(
WorkInterface.getClass().getName() ); // ServiceException (only found at runtime):
SuperWorkInterface wi =
sm.lookup( SuperWorkInterface.getClass().getName() );
// ServiceException (only found at runtime):
SuperWorkInterface wi = sm.lookup( MyComp.getClass().getName() );
}Concretely; The analogy often brought up is the cast at a theatrical play. The play consists of Roles. There are any number of Actors. Each actor plays one or more roles. This setup is clear, now...
In Avalon, the Role is the ROLE, and the Actor is the component.
Does anybody find the fault in the logic/analogy above?
yep. Analogies are flawed by definition :D
The ROLE is part of the PLAY. The Actor performs the Role. The Same Actor (read component) can perform (in a theatrical play) Any Role of the Play. The Actor's interface (in a theatrical play) is his/her experience/training/understanding of Acting, so that the director can issue directives like "be more subtle in the expression of grief" (which I, non-Actor, wouldn't have a clue what that would mean).
I can't see how this is the case with Avalon Roles. Is the PLAY restricted to a single interface and a single Role? Probably not. Then if a bunch of interfaces makes the Play, then I can't swap the actors to play the different roles. In fact, it is like saying one particular actor can only play one type of Roles.
yep.
But then, someone will say, a component can implement many different interfaces and by that play many roles
yep, but that's a bad idea. A component should do one thing and do it well.
I am more against the terminology (ROLE) than I am against the use of String as lookup, and Leo's version of encoding lookup information into that String.
I also know that the terminology has been around quite a while, but that doesn't mean it is good (compare War).
+1
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
