AOP Refactoring: In-class aspects to improve code
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?
Not a good example
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.
Re: Not a good example
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.
Re: Not a good example
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.