Introduction to
Aspect-Oriented Programming
Martin Giese
Chalmers University of Technology
Göteborg, Sweden
AOP Course 2003 – p.1/14
Pros and Cons
AOP Course 2003 – p.2/14
Pros and Cons
(Does it Make Sense?)
AOP Course 2003 – p.2/14
Positive Positions
• The inventors of AOP think it is good.
• A growing user community thinks it is good.
• People who have had good experiences write books about it.
• Some people even give courses.
• Positive results still too recent to see what code looks like after 5 years.
• No quantitative, “metric” results on benefits of AOP.
(But then, these are rare in SE anyway.)
AOP Course 2003 – p.3/14
Critical Positions
• Probably many people are critical towards AOP in principle
• Still hard to find scientifically founded criticism in the literature.
One example:
“AOP: Does it Make Sense? The Case of Concurrency and Failures”
by Jörg Kienzle and Rachid Guerraoui (Lausanne)
Suggests that transaction management, though crosscutting, is hard to
separate into an aspect.
• More case studies needed, more publications also on limitations of the
idea and languages.
• This lecture: very preliminary summary of experiences
AOP Course 2003 – p.4/14
Language Extensions
Contra: Language extensions are evil. I can only use one extended
Java compiler at a time.
• Remember, it is possible to do all you can do with AspectJ using
libraries like Nanning or AspectWerkz.
• Still, it is hard to say how these would interact with other language
extensions.
• Many now-standard language features started as add-ons.
AOP Course 2003 – p.5/14
This is Not New
Contra: This can be done using macros (wrapping code),
MultiJava (mixins), etc.
• True. AOP has incorporated ideas that were there earlier, trying to unify
them.
• Does provide more type safety and more power than usual macros.
• Still more restricted than general program transformation
AOP Course 2003 – p.6/14
Hard to See What Happens in the Source
Contra: When I look at the source, I don’t see all the advice that does
strange things behind the scenes.
• You are supposed to use AOP with IDE support that does tell you about
advice wher it is added in the source code.
• Ideally, AOP is about not knowning, and not needing to know about
advice when you write the business logic.
AOP Course 2003 – p.7/14
What When the Code Changes
Contra: When I restructure the business code, I will have to look through all
my advice, to see if it is still valid.
• You should avoid tight coupling in aspects just as everywhere else.
• People have started to investigate refactoring in the presence of
aspects.
AOP Course 2003 – p.8/14
Pattern Matching Easy to Break
Contra: When I change the signature or the name of my methods, I might
inadvertently break an aspect that uses a pointcut relying on the signature.
• Changing names and signatures is a global action anyway. A correct
refactoring would just take aspects into account.
• Depending on the applied pattern matching, this might not be
possible
• IDE support can tell you when an aspect relies on a particular signature,
making it less likely to remove something from a pointcut without
noticing.
• Future metadata support could make things better.
AOP Course 2003 – p.9/14
Cannot Reason About Aspects
Contra: It is usually impossible to modularly describe the meaning
of an aspect on a semantic and not syntactical level. This makes it
impossible to reason about it in a modular, scaleable way.
• Might be possible in cases where the actions of the aspect are clearly
orthogonal to the ones of the business logic (tracing).
• Don’t forget that modular, semantic specification of OO software is still
an open problem.
AOP Course 2003 – p.10/14
Deceptive Simplicity
Contra: It looks simpler than it is. E.g. what happens with
Worker Creation if the required context changes?
• you get the same problem when you create your workers by hand.
• Right, but then they don’t look so simple.
• writing aspects is for experts.
• On whose real-world system am I allowed to practice?
AOP Course 2003 – p.11/14
Too Complicated to Specify
Contra: This language seems to be too complicated to write a decent
language definition for it. Look at the mess with call/execution. Or the
interaction of advice and inheritance. Or the interaction of privileged with
private member introduction.
• They didn’t have the personel or the money to write it that Sun had for
Java.
• The language is still evolving.
AOP Course 2003 – p.12/14
Too Powerful Ways to Write Bad Code
Contra: There are many potentially dangerous things here. For instance,
softening exceptions might be too tempting for the average programmer.
And it’t easy to use it for ad-hoc patching.
• writing aspects is for experts.
• C++ was powerful and dangerous. When we understood what power
we need, and what danger we can avoid, Java was created. Let’s start
with a dangerous AOP language.
• But then, some of this can already be done in less dangerous ways.
Mixins, domain specific languages.
AOP Course 2003 – p.13/14
Conclusions
AspectJ is not a mature technology. It is, after all, young.
But:
• An important problem was recognized and stated.
• Pattern candidates can show what is needed for future development.
• Experience will show which usages are successful and stable.
• Future language development can prohibit dangerous usage.
Let’s hope for the best!
AOP Course 2003 – p.14/14