Win a copy of Functional Reactive Programming this week in the Other Languages forum!
    Bookmark Topic Watch Topic
  • New Topic

Why shouldn't we use AspectJ/AOP?

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Report post to moderator
What are scenarios that we shouldn't use AspectJ/AOP?
 
Ramnivas Laddad
Author
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator
There aren't really any technical reasons to not use AOP/AspectJ (of course, for AspectJ, the use of Java is a prerequisite). There are, however, non-technical reasons such as lack of an internal champion who understand AOP/AspectJ reasonably well, lack of understanding of OOP and AOP, and such.

Basically, this is not that different than if the question were to be change to "Why shouldn't we use Java/OOP?".

-Ramnivas
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Report post to moderator
Thanks. I think using AOP adds more technical complexity to the project. If we're using OOP in a project and not all members understand OOP well, it might not be suitable to introduce AOP (which almost team members don't understand it) and heavily use it.
What do you think?
 
Ramnivas Laddad
Author
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator
AOP actually reduces technical complexity; however, it requires that developers working on the AOP portion of code understand it well. Like any other technology, AOP can be learned. So it becomes an issue of gaining competitive advantage by using AOP vs. putting effort in learning it.

-Ramnivas
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Report post to moderator
Ramnivas Laddad wrote:AOP actually reduces technical complexity

I don't see how it reduce technical complexity.
For example, if we don't use AOP and want to do logging, the code will be very simple (actually it's simplest):

Technically, it's simplest, developers don't need to know anything except method invocation. But if we use AOP the code will become:


We have to create aspect, define advice, pointcut. Developers need to understand what is aspect, advice, pointcut, etc. This clearly adds more complexity to the project, and adds more things developers need to know.

Surely, AOP can be learned, but I'm interested about what is the point that even if it adds more complexity it's justified to use AOP.
 
Ramnivas Laddad
Author
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Report post to moderator
Map this example (or even better something like transaction management, security, or concurrency control) and you will see that learning AOP and implementing aspects is far better than repeating code in hundreds of places. For example, see code in freely downloadable chapter 10 to see if that helps convincing yourself if AOP reduces complexity.

-Ramnivas
 
John Grath
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Report post to moderator
Hi. This looks like an old post. Spring 2.5+ handles this rather well.
Like everything in Spring you need to learn it before it becomes easy. I think Aspects are very useful in Spring and worth learning.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Report post to moderator
John Grath wrote:Hi. This looks like an old post. Spring 2.5+ handles this rather well.
Like everything in Spring you need to learn it before it becomes easy. I think Aspects are very useful in Spring and worth learning.


Yes, this is an old post. So I am going to close it so it isn't resurrrected again. ;)

Thanks

Mark
 
    Bookmark Topic Watch Topic
  • New Topic