CODEWITHSUNDEEP
programming-languagesaspectjspring-aopaop
Geni
Geni

Reputation: 707

Aspect-Oriented Programming Weakness?

Is there any major weakness for aspect-oriented programming? I like the idea of alleviating crosscutting concerns by limiting the calls towards one class inside its aspect. But to me, it is a little bit weird.

Question 1. Let's take the Logger class example. Every class/method may need to call some method of the Logger class. Writing all those calls inside the Logger aspect makes future modification easy. However, who should maintain the Logger's aspect? If the developer of the Logger class does this, he/she needs to have a global view of the whole project, which I think is kind of impossible if the project is large enough. On the other hand, if we allow everybody to modify the Logger's class, there will be too many people accessing the same piece of code. And if any of them makes a mistake, the code will fail. So, in general, who should maintain the aspects?

Question 2. Will the performance be a problem? I think one pointcut is like registering one event listener. If there are too many pointcut during runtime, will it slow down the program?

Thanks,

Upvotes: 4

Views: 1385

Answers (1)

jstephenson
jstephenson

Reputation: 2180

Question 1

I think this largely answers the question: the Logger aspect is not the same as the Logger class/implementation. So whilst the Logger implementation can exist in some standalone unit which indeed performs the task of logging, any logging aspect(s) exist within your application's domain and they can defer the work at their intercepts. The responsibility is therefore localised to the entities for which the aspect is being applied, which makes good sense.

Question 2

Perhaps of interest.

Performance will be very specific to implementation, and I don't know in detail how anyone does it, but at a guess in a compiled (or effectively compiled) situation it would not infeasible to effectively 'inject' the aspect's behaviour into the appropriate places (or things to achieve a similar end) and as such the performance hit would be minimal.

Take this into interpretted languages however, and you are effectively indeed in the 'event listener' style of overhead.

Weaknesses

I'm no expert, but I'll draw a couple of conclusions and invite any additions:

  • Lack of visibility. Can't see by looking at the target which aspects are affecting it, could lead to debugging difficulties - particularly if affecting the code flow. Good IDE support could probably alleviate this.
  • Could perhaps lead to larger binaries when aspects are compiled into the code, though I'd imagine this to be negligible.

Hope this helps.

Upvotes: 6

Related Questions