------
You may have noted that we have some marker interfaces (interfaces with no members) in avalon-framework (ThreadSafe & SingleThreaded), and we have found they're not very nice. Similar for many other problem domains.
The option we're moving to now is to express information like this not using "pure" OOP constructs like inheritance, but to attach some additional meaning to your entities in some other way.
What you have here is a desire to mark some otherwise indistinguisable avalonified component as an Aspect, which has some special meaning in your application.
Who marks it as such? The guy developing the code, or perhaps someone porting the code to your AOP system, or both, or perhaps a container that has decided to AOP everything and dynamically wrap components as aspects?
Clearly, it is often difficult or impossible for others but the original developer(s) the change such a marker. Can a component which is an aspect also be used in other ways? If so, you want others to be able to do that.
How do you mark it? The traditional OOP method is to introduce a class or interface. More modern OOP may introduce an accompanying class (MyComponentAspectInfo, like MyComponentBeanInfo), or require an implementation to provide some kind of class member to return such an object ( interface Bean { BeanInfo getBeanInfo() } ).
Current developments take us to providing this data in other ways. .Net is leader of the pack atm in terms of usable setup, where a type can be associated with an attribute ( [aspect.IsAspect] class MyComponent {} ), and java is moving this way too (JSR 175). We're looking at how to do this in avalon; currently there's a mix of approaches. One is to use xdoclet or qdox to mark a class using special javadoc tags, and transform those tags into xml files stored with the tags at compilation. The xml tags can then be modified later if desired.
If you were to go that way here, instead of having the Aspect interface, you might have something like
/**
* @aspect true
*/
class MyAspectImpl implements Servicable, Startable {}There's many pros and cons to each approach, so choose what fits your application and in what environment you want to be using your components.
------
What you should note is that your current Aspect interface is still a plain marker interface, while imposing artificial additional requirments on Aspects (namely that they should always be serviceable and startable). You should only do this if you are 100% certain that these constraints make sense.
You should also note that your current aspect interface IIUC things correctly, does not fit under what we normally call "work interface" (as it defines no methods which allow a client to tell your aspect to "do something"), so all the guidelines wrt work vs lifecycle don't really apply.
------
doubting this helped, but have fun!
- Leo
Olaf Bergner wrote:
One note, though: you made the interface Aspect extend Startable and Serviceable. While being no expert in Avalon concepts I still think that this restricts your flexibility when it comes to implementing that interface. I made it a habit of not letting the work interfaces of my components extend any lifecycle interfaces. Work interfaces and lifecycle interfaces describe two very different ... well, may I say, aspects (?) of any given component. Work interfaces provide the client's view on the component whereas the latter describe the container's view. The client is and should not be concerned with the pecularities of the component it uses.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
