[aosd-discuss] "AOP considered harmful"

[Juri Memmert]

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

Ron Bodkin wrote:

Ron,


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

I agree that for most projects, an informal, incomplete design is more
than enough... it is for most of mine. But still, if I add some vital
information through an aspectual approach, I will be damned on the long
run if I do not, on the design level, discuss there these parts fit. And
if I do that in the typical manner for OO projects, I will point out one
of a few places where this actually happens and design them...

So, I would use the class with n methods in most of the model, but in
one diagram, I would somehow have to show how the augmented class looks
like and what it does.
Since there's no support for aspects in design (yet?), I would have to
create a virtual class that contains more methods than the original
class, more state, more behavior.

But that's quite hard to show with a tooling where the same class, with
the same methods, can only appear once in the model. So I would either
have to go for subclassing or would have to maintain two classes in sync
(at least for a while). This sucks and makes the model even more
unreliable than normal OO... something I would like to avoid, given the
inherent unreliability of designs in OO.


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

I better do, otherwise, I can't write a subclass and have it work
successfully... even if the knowledge is just informal. And with an
aspect, I want the same, unclear but existing knowledge, no more (more
would be nice, but I am a practitioner and do not deal in dreams).
This is very hard with many of the constructs AOSD tools allow me to use.


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

Oh, I agree... the added complexity breaks our necks in more projects
than we would like to accept.


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

Since the complexity of a system with AOSD is at least as big as one
without AOSD, the number of modules and thus the lower per-module
complexity in AOSD systems is indeed a gain, no doubt about that. But
complexity that I can track and trace statically, without having to rely
on guesswork and looking up the specific pointcut definitions that apply
is easier to handle.
Let me give an example... I spent tracing a call through a large
application this morning... one call went through about 90% of the
components, but not in a straight-forward manner but weaving back and
forth, touching this and as an effect touching that, which as another
effect touched something else... and so forth.
Since I wasn't sure where the problem originated, I could not dismiss
most of the call stack and had to go through it in full. This sucks in
OO as you well know.
Now imagine that, instead of going through the code in standard OO, I
would have to go through a code written with AspectJ. Then, in a variety
of places, I would have encountered aspects that would apply. Dismissing
stateless aspects, only focusing on the stateful ones, I would have to
keep track of all calls to that state (and its effects) throughout the
call chain until I could safely decide that the aspect wasn't the
culprit (or I found where it did mess up).
This is an additional set of complexity that I would very much like to
avoid... Yes, aspects make designing and writing code easier, but they
do not necessarily simplify tracing a call or understanding how the
aspects interact with the base application or amongst themselves.


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

Almost, but close enough.


> 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 couldn't agree more. But in contrast to you (maybe), I would like to
make these sound principles and design decisions sufficiently explicit
for people not to forget them and be able to reason about them easily,
outside the code, on the requirements, analysis and design level.


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

I think a lot of the technology is useful today, I give you that. But
mature? Technically, yes. It does what it's told, repeatedly, without flaw.
But conceptually? I don't think so.

If you look at the typical developer, there are a lot of developers who
hardly understand separation of concerns, lean interfaces and creation
of coherent classes. Giving them AOSD is like giving them the solution
to all their problems... they can now scatter code snippets across their
application at their leisure and still claim they're hot. ;-/
Giving them a framework of concepts and thoughts that show them that
this is not what good programming is would be beneficial... and tool
support on the code level, while critical, is not enough on its own, imho.

A reason why packages work is because all code in one package is,
supposedly, governed by some common idea. net.jpmdesign.concern.model
clearly deals with something different than net.jpmdesign.transactions.
Two concerns are at work here and they are clearly separated (in name at
least).
Knowing where one calls the other, be it through aspects or normal
method calls gives you an understanding of how these concerns
intertwine. In the case of normal OO, this is easy. In the case of AOSD
approaches, this can vary from easy to quite hard.
But doing this on the code level only is not enough since there is some
design document that details that net.jpmdesign.transactions merely uses
the container's transaction mechanism (or doesn't) and there is an
analysis document that states why this has been done. You need the
traceability between these to justify what you do in code. You need the
traceability to understand what you're doing when you implement
net.jpmdesign.transactions.beanManaged and where it applies to
net.jpmdesign.model. And code doesn't tell you that. No code or
commentary ever does (unless you document way more than any other
developer I ever saw... but in that case you have analysis documentation
in your code).


	Juri


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCb+S/dlXiXRccbPMRAg/aAJ4nxUOs+JNz8w063lVCYmQjwYgkDQCgz1jQ
bNsiyGo3LVRH1wlTdJ7+jxk=
=Rk2d
-----END PGP SIGNATURE-----