[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-users] Re: [aosd-discuss] AOP myths and realities article published
|
Inline...
Renaud Pawlak wrote:
Hi Ramnivas, very nice article!
Thanks. I hope it makes developers understand the real value proposition
of AOP.
I was a little bit intrigued about an apparent contradiction when I
read the paper.
Between
Myth 2: AOP doesn't solve any new problems (which appears to be true
in your article...)
and
Myth 12: AOP implementations don't require a new language (which
appears to be false in your article)...
What seems awkward to me is: why would we need a new language when AOP
does not solve any new problem??
AOP is a new way of solving old problems! None of the modern programming
methodologies solve any new problem. I use the following as part joke,
part reality during my talks on the same subject: "If you are motivated
enough, you could write an enterprise application in assembly language".
In a sense, new methodologies merely provide new engineering techniques
to combat growing complexity and AOP is no exception.
Therefore, it is the new way that requires using a new language.
If, as you state in your article, "AOP isn't a new computation
theory", then why would we need a new language. In other words, what
does Java not support in the panel of existing computation theory that
requires its extension for doing AOP?
Just for the same reason, Java (or C++, smalltalk etc.) needed to create
a new language to solve the same problem that C and perl solved (and
continue to do so).
Of course, it is an open question, but I think it is hard to answer
without defining exactly what AOP is... which is an exercise I won't
even try to do here :)
/Renaud
Ramnivas Laddad wrote:
Hello,
IBM developerWorks has published my AOP myths and realities article
(http://www.ibm.com/developerworks/java/library/j-aopwork15). In this
article, I examine the following common myths around AOP and discuss
their realities:
* AOP is good only for tracing and logging
* AOP doesn’t solve any new problems
* Well-designed interfaces obviate AOP
* Design patterns obviate AOP
* Dynamic proxies obviate AOP
* Application frameworks obviate AOP
* Annotations obviate AOP
* Aspects obscure program flow
* Debugging with aspects is hard
* Aspects can break as classes evolve
* Aspects can’t be unit tested
* AOP implementations don’t require a new language
* AOP is just too complex
* AOP promotes sloppy design
* AOP adoption is all or nothing
-Ramnivas
