 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-04-24How Do We Safely Orient for Aspects?Slashdot | Aspect-Oriented Programming Considered Harmful. My first exposure to AOP was in the way that Kiczalis talked about having implementations be exposed in an appropriate way beneath or on the side of abstract interfaces. I thought of this as an interesting idea for optionally, conditionally, and dynamically optimizing an integration of components without torpedoing the abstraction. My mental picture was always anchored to the prospects of a nice fit with something like the IUnknown::QueryInterface provision of COM components, and I often find applications that take that form in crafting interface-based component frameworks. Later, I read that AOP is about cross cutting, a much more difficult notion. The idea is appealing, and I think of it as useful in terms of multiple patterns and architectural perspectives across a single system. The trick, if I understand it, is in maintenance of aspects such that they are each dealt with in their own locality and as separated concerns, yet the implementation must have accommodation of each aspect distributed among its objects such that the aspect is realized and the objects integrate properly. That's my basis for wondering what this cautionary analysis is all about. The notion of aspects is very compelling, but maintaining a coherent integration of objects that honors multiple aspects seems difficult and also not something done light-weightly. I'm not concerned so much about this to pay $50 per page for the Forrester report, and I can't confirm nor deny the relationship to the "fragile pointcut problem" in the work of Maximilian Stoerzer and Christian Koppen. The analogy with the harmfulness of "Go To" (and the need for a kind of "come from," arguably even more harmful) is interesting though. The advantage of the structured-programming model was that it was possible to inspect a local part of a program and see all of the control relationships and only the control relationships that had any bearing on that structural element. (We still had to cope with assignment-statement considered harmful, but great progress was made just the same.) My initial, simplistic understanding of AOP doesn't change that. The cross-cutting idea does, in that looking at a locality doesn't necessarily present all of the interactions and dependencies, and those can be changed without any indication in the piece of program you are looking at. Somehow, divide-and-rule must be preserved in a way to avoid difficult, brittle situations. It would appear that is indeed the challenge and the current AspectJ point-cut approach leaves much to be desired. You can look at the fragile pointcut as an exception that can return control, and in the general aspect-oriented case, the rule for throwing the exception might not even be visible in the code under examination. This challenge has me rethinking exceptions that can return control, too. In regard to trustworthiness of code, I now realize that I must be leary of languages that don't require accounting for exceptions with something like strong typing and explicit declaration, too. I think the cross-cutting notion of aspects is of great importance in software engineering and in the pattern and design level. I am not so sure that we have figured out how to carry it down to the maintained form of the code in a non-brittle way. At this point I must plead ignorance and remain alert for more contributions on the topic.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |