AOP - a poor man's excuse for writing ugly code
Let's take two examples that are given in any AOP language, logging and context passing.
AOP takes pride of the fact that it allows "injecting" code at the
beginning and at the end of any method (specified using sophisticated
"regular expressions"). But does this really qualify as a logging and
tracing mechanism? Not really. Any non-academic application has
functions with multiple exit points (although this on itself can be
called a bad programming practice) with multi-branch logics inside.
Typically I would have 5-8 log points with various log levels. The
important lines that i wish to log most certainly lie inside the code.
Each line prints information on specific objects. Moreover, these
messages must be localized using DB (or configuration XML file) and
filtered based on the log level that can change at runtime (presumably after an erroneous behaviour is spotted). AspectJ most certainly does not provide any means to do this.
Second, context passing. Now we have a stack of 10 functions and we
need to pass additional parameter to the innermost function. Now we
have two cases: there are already way too many parameters and we don't
want to pass an additional one (this is called not modular in AspectJ
tutorial); or we have some class that contains all the arguments and we
are too lazy to change it.
The second case is obvious - it costs next to nothing to put an
additional member to this class without breaking the modularity. The
first one is more tricky. If you have already 15-20 parameters for each
function, than your coding practices really suck. If you are unwilling
to add a parameter to a function that doesn't really need it, but has
to pass it to another function that does, you should rethink the design
of your functions. In any case, "pushing" a parameter into a code that
wasn't designed to handle it is very bad design. Moreover, this forces
reading multiple files in order to understand what each function does.
Another examples of AspectJ from the tutorial in short:
pre and post conditions - should really be a part of the methods
(especially in Java where you should be able to read the Javadocs to
understand what is the contract and when the exceptions are thrown)
- contract enforcement - covering up for a bad design.
- configuration management - via standard resource bundles, property files and Ant configuration.