Skip to main content

AOP: The Sanity's Madness

Posted by schaefa on March 8, 2006 at 2:39 PM PST

Greg Hamilton blogged about href="http://weblogs.java.net/blog/kgh/archive/2006/03/aop_madness_and.html">AOP:
Madness and Sanity talking about where and where not to use
AOP and I nearly threw up, figuratively speaking, of course. Primary
AOP is a concept that wants to relive the developer from some of the
constraints of traditional OOP. I say traditionally here because J2EE
is some sort of a AOP light framework already using some of the AOP
concepts even though it is not really AOP by any stretch of
imagination. In addition he said that the AOP allows the add code in a
cross-cutting concerns manner but I think that is not the most
important feature of AOP even though it is the best selling point
because it can be illustrated quite easily. For me the most important
feature of AOP is what I call "feature merge" or "loose integration"
meaning that I can take two or more components and massage them in a
way where they can interact together without actually changing their
code base. I think that is actually what Greg's thinks is the bad part
of AOP and he said that only Container based AOP is good because it is
well defined even though I know too many J2EE developers who do not
even understand the basic concept of J2EE transactions good enough to
work as a J2EE developer. But Container base AOP is somewhat weak, very
limited in its scope (not everything is an EJB in Java) and very rigid.
On the other hand I am quite surprised that after the past where Sun
said that JBoss will not pass the certification because it allows the
user to change the way J2EE framework works by changing the
interceptors I now see that interceptors are part of EJB3
specification. So I guess that JBoss has prevailed with its vision of a
dynamic J2EE.

If I am going to use AOP then I need a very compelling reason
and J2EE is not going to cut it. Therefore I crafted the title to
indicate that AOP is not here to be squeezed into a container but to
free us from the constraints of OOP and therefore we have to free AOP
from any container. If you want to be on the safe side and do not want
to explore the final frontiers of software development then AOP is not
for you. AOP is difficult, hard to debug and sometimes risky to
use but you can gain a lot from it:  style="font-weight: bold;">no pain, no gain.
AOP is not here (at least currently) for the weak but for the brave who
dares to push the limits to make things easier. I can promise you that
you will be frustrated quite a lot and you will fail several times
until something is working as expected. But anyone how made the
transition from procedural programming to OOP or hierarchical to
relational DBs can hopefully use his/her experience to understand the
difficulties in the transition from OOP to AOP.

Oh yeah, annotation has to end up here because it is so great,
isn't it !?! Annotation in EJB3 makes the whole thing only complexer
because I now need a tool to know what is a remote interface, an ejb
and what the actual JNDI name is because it is buried insight the
bytecode rather than to have it explicitly insight an XML file.
Annotations are just a way to tag elements in a class, nothing more and
nothing less and so do not have anything to do with AOP. Most AOP
systems like AspectJ or JBoss AOP provide support for annotations to
declare aspects, pointcuts etc but especially for AOP I prefer to keep
the definition outside of the source code because I want to be able to
change it without rebuilding the project.

Any paradigm shift is painful because we have to give up our
comfort zone in order to conquer new ground but it is not done by
restriction. Christopher Columbus would not have found America if he
did believe into world's view of that time and so sanity can be the
madness of human evolution. Don't get me wrong if you are happy with
you have and you want to code Java for the rest of your life then be my
guest but do not expect that the world just stops spinning
because of you.

-Andy