Re: [aspectj-users] Making Everyone Happy

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

If you want to go further down that road, you could put
the stub methods in a superclass of the foundation class.
Then the aspect implementations would override the
supertype 
stub implementations.

As a variant, your aspects can declare interfaces for
likely
mixin's - e.g., IAccount, IUser - along with their 
implementation methods.  Then declare that the supertype
implements those interfaces.  Then on a client by client
basis you can replace references of type {Foundation} 
with the appropriate interface (which can be a pure java
interface so you can build partial systems in javac).
That way you pare down a dependency on a god class to
one on its components. For those clients that inherit 
from {Foundation}, you can instead declare that they 
implement the requisite interface.

hth - Wes

On Tue, 04 Oct 2005 19:22:44 -0700
 Shawn Potter <spotter@xxxxxxxxxxxxxxxx> wrote:
> I have an issue where we have a "foundation object" class
> that screams
> aspects. It was agreed that this object would contain
> behaviour other
> classes should have... but of course with single
> inheritence this
> becomes a difficulty if you cannot extend from this
> object.
> 
> I converted the object to static intertype based aspects
> and as an
> interim measure I cross cut into the foundation object
> and removed the
> code that was originally in the foundation object. (the
> intention is to
> determine which behaviours should be in the other classes
> and use
> annotations to include them at a later date...).
> 
> The first issue is that many of the developers involved
> don't have
> AspectJ installed in their IDE or may not be able to run
> with AspectJ
> (outside of our Ant builds which are fully iajc).
> 
> There is also a concern on productivity since the IDE
> based compilation
> can be costly due to excessive re-compiles etc.
> 
> It has been suggested that I make the code compilable
> under javac by
> implementing dummy methods in the foundation object,
> since this was used
> for other pointcuts already in use (but only for the ant
> compile).
> 
> The biggest problem I run into with this approach is that
> the methods
> defined in the foundation object cause a conflict with
> the static
> intertype:
> 
> inter-type declaration from
> foundation.aspect.EqualityImpl 
> conflicts with existing member: 
> void FoundationObject.addToEquate(java.lang.Object)	
> EqualityImpl.aj	
> 
> Which is expected by default due to the
> intertype/interface providing
> the core behaviour.
> 
> How can I resolve this so the developers not using
> aspectj in their IDE
> can compile with the dummy code and the aspects can still
> be woven into
> the foundation object.

> 
> Is there a annotation like @dummy to indicate that this
> is a fake
> implementation and should be overridden by the aspectj
> compiler?
> 
> I guess my other approach is to make this a non intertype
> solution and
> crosscut the methods using pointcuts...
> 
> thanks,
> 
> Shawn Potter
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users