Adrian Colyer ist als AspectJ Projekt-Leiter einer der Leute, die AOP wirklich gut verstehen. Außerdem hat er gerade neu bei Interface21 angefangen (als Chief Scientist) und durfte nun auf der WJAX präsentieren.
Spannend war schon der Einstieg mit großen Namen wir Parna oder Dijkstra. Interessante auch der Gedanke des Rise and Fall and Rise of OOP. Der Fall natürlich Java EE und der zweite Rise Spring.
Das erste inhaltliche Konzept, das ich interessant fand, war die Idee, einen dünnen Aspekt mit einer Strategy zu kombinieren, die dann die wirkliche Funktionalität implementiert. Dadurch kann man dann das, was in dem Aspekt gemacht werden soll, durch Dependency Injection definieren: Man verwendet einfach ein andere Objekt.
Seine Sicht auf Annotationen ist, dass sie Informationen über eine Methoden oder Klasse geben und keine kein direkten Befehle sein sollten. Gut ist also @Transaction, schlecht @StartTransaction. Gut ist auch @ReadOnly, schlecht wiederum @AcquireReadLock.
Ein interessantes technisches Problem, dem er sich dann widmete, sind POJOs, die zwar von der Anwendung erzeugt werden, aber durch Dependency Injection konfiguriert werden sollen. Ein Beispiel sind Domänen-Objekte wie Kunde, die dann eine Referenz auf einen Dienst bekommen sollen. Dazu ist eine Trennung zwischen Konfiguration und Erzeugung notwendig. Das bedeutet, dass die Objekte einfach mit new erzeugt werden, aber dann durch Spring konfiguriert werden. Dazu ist dann eine Annotation wie @SpringConfigured("KundeBean") notwendig. Der Parameter ist der Name der Spring-Bean, die dann in der Konfiguration gesucht wird. Default ist der Klassenname. Zur Implementierung dieses Features ist ein recht einfacher AspectJ Aspekt notwendig, der auf das Erzeugen von Objekten reagiert.
Obwohl dies ein cooles Feature ist, bin ich noch nicht sicher, ob es wirklich zielführend ist, da die Domänen-Objekte meiner Meinung nach nicht unbedingt die Services kennen sollten. Spätestens in einem Szenario, wo man ein solcher Objekt von einem Server auf einen Client übertragen will, hat man da ein Problem.
Soweit also die Möglichkeit, Annotationen zur Markierung für Aspekte zu verwenden. Eine andere interessante Möglichkeit, die Adrian noch zeigte, ist es, einen Aspekt dazu zu verwenden, Annotationen zu bestehendem Code hinzuzufügen. Dadurch kann man in der AspectJ Pointcut Sprache definieren, wo bestimmte Annotationen gesetzt sein sollen. Zusammen z.B. mit den Annotationen für EJB 3 könnte das eine ganz coole Vereinfachung sein... ¶ 17:04
