Future of Aspect Oriented Programming [closed]

Asked 6/6, 2009 at 6:48 Answered 6/7, 2009 at 5:32

I am a newbie in the area of AOP. The first time I coded something applying concepts of AOP, I was thrilled to understand how aspects eliminate cross cutting patterns in your application. I was overwhelmed by the thought of solving cross cutting patterns like security, logging, transactions, auditing and etc applying AOP.
However, when I first proposed usage of AOP to the client I am working for, I was told that they don't support it. I was told that AOP means more maintenance! Your pointcuts have to change if your code changes. Hence, you might have to analyze, change and test your aspects whenever you change the code to which they were applied?
What do you have to say regarding this? Why are mainstream companies not open yet to extensive usage of AOP? Where is the AOP world going?

Malleolus answered 6/6, 2009 at 6:48 Comment(5)

I see you have created this question for that long named tag that is actually cut off quite a bit. You are not going to achieve the taxonomist badge that way. – Grandioso 6/6, 2009 at 6:53

@Ctrl Alt D-1337 I am not sure what you are talking about? I am not here for badge collection. – Malleolus 6/6, 2009 at 6:57

programmi? stackoverflow.com/questions/tagged/aspect-oriented-programmi – Grandioso 6/6, 2009 at 7:2

it was a typo! i tried editing and correcting it, that didnt change it! – Malleolus 6/6, 2009 at 7:11

@Ctrl Alt D-1337, new users aren't yet spoiled by badges. :) – Gesticulative 6/6, 2009 at 8:6

AOP is a relatively new concept, and large companies are generally wary towards new concepts. They fear getting stuck with a lot of AOP code and unable to find people who can maintain it.

Regarding the specific criticism, it seems uninformed or misunderstood. The whole point of AOP is to reduce maintenance work by reducing code duplication in the area of cross-cutting concerns. However, it is true that it can make maintenance more difficult by making it harder to understand the the code - with AOP, when you look at a particular piece of code, there's always the chance that an aspect defined somewhere else completely changes its behaviour.

Personally, I'm not sure the benefits of AOP (are there really that many cross-cutting concerns?) outweigh this problem. The only way to I can see to solve it would be through support in IDEs; but making you even more dependant on an IDE isn't such a great thing either.

The trend seems to be towards app servers and frameworks that address specific, important cross-cutting concerns like transactions and security in a similar manner as AOP (i.e. central declarative definition) but without giving you its full power to confuse maintenance developers.

Charlottetown answered 6/6, 2009 at 7:48 Comment(7)

I've recently watched a presentation on Google Video about AOP (video.google.com/videoplay?docid=8566923311315412414). There, Gregor Kiczales, basically said AOP relies on IDE support (that's what I understood anyway) and I think this unacceptable. – Gesticulative 6/6, 2009 at 8:5

Not really. I can do AOP with Spring using TextPad. It's all configuration. Why is an IDE necessary? – Toga 6/6, 2009 at 11:40

@duffymo, necessary for maintainability of code. The IDE would show you what portion of code has defined aspects. – Gesticulative 6/6, 2009 at 16:47

I don't buy that "relatively recent" argument. AOP has been around for 35 years. .NET has been around for less than 10, and that doesn't seem to be a great barrier to adoption. – Carcinomatosis 6/6, 2009 at 19:10

Care to back up that claim? It's certainly not brand new, but I find 35 years hard to believe. OOP is is not much older, yet took at least 20 years to become widely adopted. Comparing this with .NET is apples and oranges - .NET is a new platform, not a new concept (and indeed little more than an arguably improved clone of Java). – Charlottetown 6/6, 2009 at 19:22

It appears that the paper which introduced most of the terminology for AOP was published in 1997, based on development work which presumably occurred over the prior several years. The earliest reference in its "Work Explicitly Connected to AOP" section is a 1989 paper. So it's not all that new, but not quite 35 years old. – Cytologist 2/5, 2019 at 18:3

@Malnormalulo: note that the comments you're replying to are nearly 10 years old themselves. At the time of that discussion, 1997 was just 12 years in the past. – Charlottetown 6/5, 2019 at 19:24

AOP is one of those things that's an interesting idea that just doesn't work all that well in practice. Java's had AOP available for a decade or more now, and it's not being used much because it seems to introduce more problems than it fixes.

Cosme answered 6/6, 2009 at 8:14 Comment(1)

So what is your practical experience with AOP? Can you back your statement with facts? My experience is totally different. AOP in general and AspectJ in particular are one of the most useful, elegant and powerful tools I have encountered in the past five years. And for me it works damn well. :-) – Fiden 15/9, 2012 at 10:1

I was told that AOP means more maintenance!

That's just silly and exactly wrong. AOP is an essential tool for getting noise out of your code and allowing you to focus your effort on delivering business value. When the business rules change you don't have to wade through miles of framework logic to reflect the new changes in your code.

Like any tool though, you have to make sure to use it correctly. I had to work around the fact that my AOP logging would inadvertantly log decrypted credit cards:

http://www.agileatwork.com/what-happens-when-you-actually-use-aop-for-logging/

Poulter answered 6/7, 2009 at 5:32 Comment(0)

I had to do some performance optimisation on an application and I chose to write a custom profiler in AspectJ. I was skeptical about using AOP at first but I realised that it was absolutely the perfect tool for the job.

However, there are many jobs that I would not use it for. I would be very wary about using it for anything that may affect application functionality. The extra layer of indirection and lack of transparency would cause too many problems for developers trying to add features or fix bugs.

React answered 6/6, 2009 at 9:19 Comment(2)

I think that AOP is NOT about changing anything in the functionnal area. It's rather about expressing functionnalities in a natural way and push computer specific considerations (optimisations like caching or using OS / hardware speficifities, logging users don't cre about ) out of the way. As with any tool you can misuse it but in that case I don't see it as a tool failure ... – Gauldin 6/6, 2009 at 14:51

I disagree with the second paragraph. Even though it just expresses a personal opinion it seems to be over-generalising at least, if not outright wrong. – Fiden 15/9, 2012 at 9:59

People forget that Java annotations and their use in frameworks like Guice and Spring were inspired by AOP. I would say Java annotations is where AOP is going today.

Keefer answered 6/6, 2009 at 14:42 Comment(1)

I disagree. Annotations are still part of the source code and mean scattering, even though less tangling (because annotations move cross-cutting concerns from the method body to the header), two of the effects which AOP can help you get rid of. If possible at all, I try to make my pointcuts match types and signatures, not annotations specifically introduced for aspect use. If there are existing annotations which are used by other frameworks, fine, I will use them for matching, but no AOP-specific ones. This is why I prefer plain AspectJ syntax to annotation-based @AspectJ syntax, BTW. – Fiden 15/9, 2012 at 9:52

We use AspectJ AOP implementation and are very happy with it. You should consider it just another part of your toolkit that makes some concepts easier to express then in 'normal' java. We currently use it mainly to provide JMX interfaces to our services.

It is true that more IDE's should support it (I'm looking at you JetBrains!), that would certainly help the adoption.

Brayton answered 16/6, 2009 at 19:2 Comment(0)

Recommended topics

Hot tags