Rickard is making a few changes in his views on AOP, more specifically on dynamicity:

Basically, each class (be it a normal class or aspect implementation) simply declares what it it needs in terms of other interfaces in the “implements” clause, but does not actually implement them.

I find this idea puzzling. While it does indeed help solve the static typing problems, since your classes and advice now really implement the interfaces that the AOP framework might have introduced on them, you are still left with the problem of object identity.

For example, in his example, the class PersonMixin declares that it implements Person and Author, but the class is declared abstract and the Java code only implements Person. The implementation of Author will be supplied by the AOP framework in a mix-in.

I don’t know about you, but my first reaction is that this reminds me a lot of how CMP 2.0 works. You work on an abstract class that only contains your business logic and all the abstract methods are generated by the container in a subclass. The difference with Rickard’s AOP approach is that he uses CGLIB to implement the concrete class and, more importantly, that the generated subclass can be controlled by a pointcut model. So far, so good.

However, unless I am missing something important, I just don’t see how this could work beyond a toy application where objects can be populated statically. The problem is that at runtime, you just don’t know what instance of Author you will be talking to. How do you make sure it’s the right one?

In the case where this class can be populated statically, you can use something like Spring’s BeanFactory to get you started. However, I suspect that in the real world, the Author object is populated at runtime. Its value is part of your business logic, and I don’t see how you can guarantee this in an AOP framework, unless you start putting the said business logic in your pointcut definition. An idea which, frankly, scares me.

Maybe you could envision having an advanced version of PicoContainer that knows about identities of objects and allows you to look them up, but do we really want to go down the path of defining primary keys in Java objects just so that we can use them in-process?

I wonder if this idea is simply not going too far. AOP makes us think about proper divisions or responsibilities and concerns, but this idiom is a step toward splitting your business logic between Java code and… some other undefined place which depends on your AOP framework.

Rickard, if I missed something, please let me know.

By the way, all these problems magically go away with AspectJ, which combines:

  • Static typing.
  • A powerful pointcut model.
  • Familiar OO concepts such as inheritance and polymorphism.