[aosd-discuss] "AOP considered harmful"

[Ron Bodkin]

Juri, I think the basic difference in our approach is that I think the code
is an executable model, and that design is best done in a fairly agile
manner with most of it being used to agree on the key concepts. I haven't
seen model-driven approaches where people maintain a model in synch with
running code actually work in practice, not even in OO. So I don't have much
of an issue with the state of tools support for AOSD design, since to me the
primary value of designs is to faciliate communication and shared
understanding among people.

Re: the Liskov Substitution Principal and adherence to contracts, I think
most real systems have best efforts informal documentation of semantics,
which is far less than a contract. So what does it really mean that you can
substitute one subtype for another? How do you know what pre-conditions and
post-conditions apply? 

To me the complexity from scattering and tangling crosscutting
implementation and the correlated "Russian Dolls" of delegation in a real OO
system is far worse than an effective use of AOP. It's not a question of
what kinds of complexity are in the system, but how much. Even though
dealing with aspects is another thing to understand and reason about, the
net benefit from the modularity makes it a big gain, in my books.

I do think having principles behind the use of aspects and a clear design is
important. Perhaps that's what you mean by a well-defined concern and
understanding how they come together? This is why people can reason about
containers and work in an environment where the container handles something:
they learn the library's semantics and how to configure it, in this case
with zero tools support. Obviously if you write aspects that aren't
coherent, that just package up a bunch of random patches, you are in trouble
and aren't writing maintain code. Every new form of modularity technology
gives more power, and some always use this rope to hang themselves.

I do think having more expressive pointcuts will further improve
expressiveness for AOP. But to me the overall state of AOP is that the
technology is mature and useful today.

-----Original Message-----
From: Juri Memmert [mailto:memmert at jpmdesign.de] 
Sent: Tuesday, April 26, 2005 10:20 PM
To: Bill Burke
Cc: AOSD; Ron Bodkin
Subject: Re: [aosd-discuss] "AOP considered harmful"

-----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-----