Archive for the ‘aop’ Category

Writing Mixins using AspectJ

Friday, December 16th, 2005

java.net has a nice long article on Writing Mixins using AspectJ. They use the example of JavaBean property change event listeners, which up to this point has been a total pain to write. Using AspectJ, you can whisk that code away into its own aspect. Your tradition bean looks clean and beautiful again, while retaining the nice functionality of event listener notification.

>Aspect-oriented programming complements object-oriented programming in many ways. One interesting complementary feature is behavior composability. This means that it should be possible to compose a class by adding behavior from different classes. OO uses inheritance and many patterns to add behavior to existing classes. AOP allows us to use mixins without changing the class inheritance hierarchy or otherwise changing the code.

>Mixins enable us to uniformly extend a set of classes with a set of fields and methods. Java does not support mixin-based programming. This article shows what mixins are and explains how AOP constructs in AspectJ allow us to use this technique to isolate crosscutting concerns, with an example. It starts with a plain Java implementation and ends with an AspectJ 5 implementation.

Pragmatic AOP with Spring and AspectJ

Saturday, December 10th, 2005

The final afternoon talk on the final day of The Spring Experience is Pragmatic AOP with Spring and AspectJ.

Aspects are modular, enhancing the value of the software overall. Aspects lead to DRY SOCs (Don’t Repeat Yourself, Separation of Concerns).

Join points are well defined points in the execution of the program.
Pointcuts are expressions that match join points.
Advice is action to take at those join points. Advice is not explicitly called, unlike methods.

Typical applications are Spring managed for data access, services, web controllers, transactions, etc. Up to now, the Domain Model has not been managed by Spring.

Spring AOP is a good fit for Spring managed beans, execution based join points, or coarser-grained service application. Or any time where the aspect is slower than the impact of the proxy itself (ie, transactions).

In Domain Driven Design, another separation of concern (SOC) is the Technical Concerns (transactions, auditing, etc) from the Business Concerns (the Ubiquitous Language, language of the business domain experts).

AspectJ is perfect for integration with the Domain Model, in contrast to Spring AOP which is good for advising the service layer.

What makes a good aspect? Does the aspect reduce coupling?