AOP Refactoring: In-class aspects to improve code

Posted by Floyd Marinescu on May 07, 2007

Sections

Development,

Architecture & Design

Topics

Design ,

Java ,

AOP

Tags

AspectJ

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:

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.

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?

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.

1. Back to top

   Not a good example

   by Cristian Herling

   "Whole try-catch blocks repeated in many methods" and "code that repeats across multiple methods in one class" are a code smell, a sign of bad design. There are valid OOP ways to tackle these problems, we don't need to throw AOP into this mix for solving this problem (if anything, the problem becomes more complex).
   I find AOP to be most successful at injecting behavior which should be kept outside of objects into the objects themselves. This interview is an example of injecting object-specific behavior into an object thru aspects, I think that we are using a sledge-hammer to knock out a mosquito.

   Reply

2. Back to top

   Re: Not a good example

   by Ramnivas Laddad

   C H,
   
   Take a look at www.theserverside.com/tt/articles/article.tss?l... and www.theserverside.com/tt/articles/article.tss?l.... Which valid OOP ways can tackle the examples discussed? We can have beneficial discussion if you can show OO-based versions of the classes shown. Then we can compare and contrast two ways of doing the same thing.
   
   -Ramnivas

   Reply

3. Back to top

   Re: Not a good example

   by Cristian Herling

   The example you mention is actually valid, I wished that in the interview you would have gone a bit more in detail, mentioning only that you would use AOP for getting rid of code that is repeated across methods is a bit confusing. If anything it raises the possibility of bad design (this is the first thing I think of when I hear these words). I would have added the link from your reply to the interview and would have referred to it during the interview, it would have made a few things a lot more clearer.
   I have 2 things to say about this example however:
   1) The aspect that you apply to the methods in questions is really a small part of a large cross-cutting concern: security. I get the feeling that the "micro-cross-cutting concern" should actually be part of a larger cross-cutting concern. If you are using a security micro-cross-cutting concern in Account.java and another one in PurchaseOrder.Java and yet another one in PeopleDirectory.java, you are basically spreading security handling all over the code-base. I get the feeling that these micro-cross-cutting concerns should be consolidated into one larger concern. Please let me know what you think about this.
   2) I think you can still go OOP in order to solve the problem by using decorators (declare interface Account and implementations SecuredAccount and RegularAccount, SecuredAccount having a link to an Account). Decorators don't react well to interface changes: let's say that you need to add another method to the interface Account, all the implementations will have to be changed, but this is the overhead for using them.
   I still think that the example of micro-cross-cutting concerns takes AOP a bit too far. However, I found the examples at the beginning of the interview very interesting because they apply AOP to cross-cutting concerns.

   Reply

• Older >