I’ve been involved in AspectJ as a user for some time now, but I can still remember my initial confusion when it came to taking what was obviously a very powerful approach and applying its advantages to my existing systems.
I could easily see areas where aspects could help. My systems exhibited cross-cutting concerns both on the macro/system-wide and micro/class-wide scale that would definitely benefit from an aspect oriented approach to the design and implementation. However, I was put off by the sheer impact to an existing system (i.e. working and often large and complex) in order to incorporate this new approach, not to mention the effort involved. I could see the advantages, largely due to a talk given by Adrian Colyer’s to the BCS in London (thanks Adrian!), but I was definitely put off by the potentially damaging refactoring operation that would need to take place. Having no obvious tools to help in the process was the final nail in the coffin for some of those older systems.
Refactoring is a big deal when promoting adoption of a new technique or approach. Refactoring is something all systems are subject to but was officially recognized as such a necessary technique in the seminal book by Martin Fowler, “Refactoring: Improving the Design of Existing Code”. When done right refactoring tools and guidelines can grease the wheels of adoption by making it easier to bring the advantages of a new approach to existing and ‘under development’ systems. When refactoring aids are done wrong, or not at all, the benefits can be limited to new systems, delaying the adoption and limiting the overall usefullness of the approach.
For these reasons the linked article written by Ramnivas Laddad provided an extremely interesting examination of refactoring for AspectJ when I was pointed to it by a posting on the AspectJ mailing list. The article shows how refactoring with aspects can be done in a prescriptive and practical manner. Ramnivas carefully considers the automated capabilities that could be incorporated as well as the more manual steps in the process. Basically, it feels that if the author himself is not working on a tool that does this for the AspectJ community then anyone who is considering doing something like this would get a very large helping hand from reading this article.
In the future refactoring with aspects in mind will hopefully be taken for granted as much as OO refactoring is today, perhaps even more. Tools such as Eclipse and the other leading edge IDE’s already incorporate varying degrees of OO refactoring aids. AspectJ is currently the most widely adopted tool for AO development with Java and is accompanied by a set of maturing tool suites such as the AJDT for Eclipse. Work is already being looked into within this rich development community and I hope that as the tools mature we will pick up on what Ramnivas has formalized in his article. In time, Aspect Orientation, and specifically AspectJ, will hopefully gain the key refactoring tools that will speed adoption of the approach by facilitating a reduction in the amount of effort needed to incorporate aspect orientation into existing systems.
It’s always interesting to hear the pitfalls that people have experienced when taking on an AO approach. If you have any comments on what I’ve said in this blog, or even better a link to people who are already coming up with the solutions to refactorization where we can all chip in, then please post here. “A problem shared is a problem that is at least visible.”
It’s always interesting to hear the pitfalls that people have experienced when taking on an AO approach.
If you have any comments on what I’ve said in this blog, or even better a link to people who are already coming up with the solutions to refactorization where we can all chip in, then please post here.
“A problem shared is a problem that is at least visible.”