[aosd-discuss] "AOP considered harmful"

[Juri Memmert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Burke wrote:

Hi Bill,

> Ron, I agree with all your statements, but can we expect the average
> developer to follow all these good practices and rules?

can we expect them to follow simple OO practices? Sometimes. ;-)


> Is there any
> good research out there on what should be removed/restricted from AOP
> frameworks/languages?

I still do not think that limiting the power of AOSD is a good thing...
and I still believe that using meta-models of the application is the way
to go. Of course, most people don't seem to be of that opinion. ;-)
If you have a model of what you intend to do... be it a decent overview
of your application in UML (or any other suitable technology) or a
concern model which identifies how the concerns of your system (and thus
ordinary OO and AOSD parts) work together... you've come a long way.
In most systems, the "danger" of AOSD does not stem from the fact that
you use AOSD... but that you use it in in a way that most people do not
understand.


> This is where I come back to JBoss's long ago message of stressing the
> use annotations+AOP.  I think this is an easier sell to these analyst
> types.

Annotations are one way to increase comprehension, but annotations are
code-level-only entities, which severely limits comprehension of WHY you
do things due to limited traceability.


Ron Bodkin wrote:
>> First off, I'd say that the best tool for understanding a system as a
>> whole is a good design. AOP improves the modularity and supports
>> traceable implementations, making it easier to understand without
>> tools support. An overly complicated OO system can be effectively
>> impossible to reason about, too.

Well... where's the good support for (most) AOSD technologies on the
design level, then, that would allow for true traceability? Where's the
design support for understanding where my (AspectJ) pointcut would
affect the system?
I know, all AOSD approaches that use plain old Java can use standard UML
to describe most of what they do... but pointcuts that are not 1:1
mappings but pattern-matching can, as far as I know, not be expressed in
terms of a design at the moment... and so there is no traceability.

I do agree that overly complicated OO systems are hard (if not
impossible) to understand and that a good design would have helped
them... but even there, there is no such thing as arbitrary merging of
functionality, just because someone messed up the naming conventions
(and yes, I know, I oversimplify because there are also other constructs
in AspectJ and other approaches do suffer from this in different forms).


>> I question this in practice in large OO systems. Without tools support,
>> finding the possible subclasses or implementers of something is quite
>> difficult, so knowing what actual implementation code will execute is
>> hard.

Yes and no. Unless you messed up your implementation, the Liskov
Substitution Principle still has to apply. And so you have a general
notion of the contracts the application will abide by. If you did break
that principle, you've already doomed your application to die a slow and
agonizing death.


>> The idea of "looking at your code" breaks down on the kind of real
>> (large) systems where modularity most matters.

Yes.  This is true... but you need to be able to capture these
modules... and pattern matching is not the way to go there... Being able
to reason about how concerns match and map is, imho.


>> Of course for
>> systems that might be extended by 3rd parties, it's not possible if
>> you don't have their extensions.

True.


>> And of course, identifying the possible implementations that might get
>> assigned to a given field can require reading all the code (possibly
>> including XML configuration files). In the case of worker objects like
>> Runnable or Action, in practice you often can't reasonably figure out
>> what will execute by static analysis either.

I agree... but it IS possible to limit the number of choices by looking
at the concern model and identifying which concern(s) apply under which
circumstances.


>> Re: the question of dynamic parts to pointcuts, that to me is
>> analogous to the fact that in general one knows which branches
>> of an if test might potentially execute.
>> Indeed, having good tools to see dynamic behavior is often a
>> requirement to understand real code. A good debugger is 
>> helpful for this, and, in fact, AOP makes it easier to trace code
>> (even incomprehensible pure OO code) to understand what's
>> happening.

I agree that tool support is very important here... but in a truly
complex system, having a marker which tells me that aspect X is applied
here simply doesn't help me one single bit... because I do not check all
places it applies, and even if I did, I would not be familiar enough
with all of it to understand whether the matching is correct or not.
Knowing that aspect X applies to 300 methods within a 10000 method
application does not help.
Knowing that an aspect applies to these 300 methods will not only not
give me the information I need, it will also confuse the hell out of me
if another aspect Y applies to 100 of these methods and 400 more
throughout the application... for now I have to look at 700 methods to
understand what is happening.
Understanding that aspect X applies to all methods in concern A and
aspect Y applies to concern B and that concern A and B intersect in
these places does.


>> I'd also note that, in practice, large project use all kinds of
>> special-case obscure artifacts to address crosscutting, that
>> are also hard to follow without tools support, but (to my
>> knowledge), don't offer good tools support either, e.g.,
>>
>> - dynamic proxies (either created by the JDK or using bytecode libraries
>> like ASM)
>> - code generators like Xdoclet (sure you can read the _generated_
>> code, but
>> how do you trace it back to the sources?)
>> - execution "containers" (e.g., Servlet and EJB)
>>
>> You might argue that these aren't OO, but any real critique of AOP
>> needs to
>> address the shortcomings that motivated such alternatives.

I couldn't agree more (although "obscure" isn't really a term I would
use here). There is no good support for many of these constructs in
design and often developers don't even care enough to understand that
there is not. But in many cases, simply stating that I let the container
do something for me (MDBs are a good example where there is hardly any
design from the calling component to the MDB) is not too bad... since
the components are clearly separated and perform their tasks
independently of one another (based on input, of course).
Attaching functionality in 300 places that I do not know by heart is
significantly different and not having a design of the interaction of 2
coarse-grained component is trivial in comparison.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCbyEQdlXiXRccbPMRAt49AKC68epSS2MmDci2Szpdd6smDqmgdACfWN2N
F/2akC1Z/WWLMAij3AuZ2KQ=
=AdMw
-----END PGP SIGNATURE-----