AOP expert Ramnivas Laddad explains how to use Aspects for refactoring cross-cutting concerns within classes (not just across classes) for things like reducing boiler plate code and potential for mistakes. How to recoganize and refactor such logic into aspects is covered, as well as applying aspects for resource management and concurrency control.
Watch AOP Refactoring with Ramnivas Laddad (23 min)
Ramnivas identifies a new class of aspects called refactoring aspects. Unlike system-wide aspects that modularize cross-cutting concerns across classes and packages, refactoring aspects modularize cross cutting concerns within classes (Ramnivas calls them micro-cross-cutting concerns), such as reducing boiler plate code that repeats across multiple methods in one class. Ramnivas suggests keeping this aspect within the same source file as the class it is operating on. Some examples:
Watch AOP Refactoring with Ramnivas Laddad (23 min)
Ramnivas identifies a new class of aspects called refactoring aspects. Unlike system-wide aspects that modularize cross-cutting concerns across classes and packages, refactoring aspects modularize cross cutting concerns within classes (Ramnivas calls them micro-cross-cutting concerns), such as reducing boiler plate code that repeats across multiple methods in one class. Ramnivas suggests keeping this aspect within the same source file as the class it is operating on. Some examples:
Let's say you have method invocation from multiple places, let's say you're doing a check permission call in most methods ofa class. Those methods are representing one conceptual thing: "the access to this class is secure". That is one concept. But however new invocations are made in multiple places. You can take those method calls out and put it in an aspect and advise all those places to make the method call. That's one of the simple aspects.Has anyone tried to take this refactoring aspects approach? What were your experiences? See also a lot of InfoQ content on AOP at: http://infoq.com/aop.
The second kind of aspect, and that's where things start to become more interesting, is exception handling policy for a class. Let's take an example: business delegate pattern. What is the typical implementation of pattern, you have a TRY block, you'll do your business delegation, you will catch any remote exception thrown during that processing during/that invocation, and then you will convert that exception into a business-specific exception and throw it. .So this whole try-catch blocks are repeated in many method, basically in all the methods that are doing delegation. Why not take all those try-cache block and put it in an aspect?