Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] AspectJ and JBoss AOP implementation

> Elizabeth Echlin Harmer  said:

> Could you explain what you mean by 'orthogonality 
> of join point models'? 
  

> Yes, because as I suggested, I believe this is one of
> the crucial properties of AspectJ, and a criteria for
> any AOP tool to scale.

With respect to pointcuts and advice, the model is orthogonal if:

  - you can use any kind of advice on any join point
  - you can write any kind of pointcut in any advice declaration
  - you can compose any two pointcuts

Now it may be the case that two kind of pointcuts compose, but always
produce a null result, for example call(...) && execution(...). That's
OK, they still can be composed in the sense that the result is well
defined.

This notion of orthogonality is critical from a practical point of 
view. Without it pointcut and advice code is very brittle.

Consider what happens if I write a public pointcut in one aspect. say
pointcut aquireResource(): ..., and then I use that pointcut in several
other places. You'd like your code to still work if I edit the
aquireResource pointcut, as long as within the domain sematics, the join
points it identifies really are points where the resource is aquired.
You'd hate for it to be the case that the code breaks if I happen to
use a different pointcut construct somewhere in the new definition of
aquireResource.

In that sense orthogonality has a real practical impact -- it makes the
code robust.

Orthogonality also makes an AOP tool easier to learn and use. In the
AspectJ model, where pointcut, join point and advice are three clearly
different and clearly orthogonal concepts, you can understand the language 
in simpler terms. 

  - If Njp, Nptc and Nadv are the number of different kinds of join point,
    pointcut and advice respectively.

  - Then in an orthogonal model, the complexity of understanding the
    language is something like Njp + Npc + Nadv.

  - In a non-orthogonal model the complexity of understanding the language
    is something like Njp*Nptc*Nadv.

That's because in the orthogonal model I can, for example, reason about the
different kinds of advice, knowing that they each work similarly with all
kinds of join points. In a non-orthogonal language I have to remember that
this particular kind of advice only works with these particular kinds of
pointcut and those kinds of join point. My mental model is much more complex.

I've described this just in terms of the pointcut and advice join point
model. But the same holds for other join point models. For example AspectJ's
introduction and type pattern facility is join point model. The points are
effectively declarations, the pointcuts are the type patterns.




Back to the top