Section 2.8. CLOSING REMARKS


2.8. CLOSING REMARKS

Understanding something involves both understanding how it works (mechanism) and what it's good for (methodology). In computer science, we're rarely shy about grandiose methodological claims (see, for example, the literature of AI or the Internet). But mechanism is importantappreciating mechanisms leads to improved mechanisms, recognition of commonalities and isomorphisms, and plain old clarity about what's actually happening. The understanding gained through the examination of mechanism leads to generalization and richer systems. The quantification and obliviousness argument is about looking for the common mechanism in AOP systems, seeing how to understand particular AOP systems with respect to those mechanisms, and looking for the places where those mechanisms can be generalized. We're trying to answer the question, "Is X an AOP system?" where the answer is not based on whether the creator of the system called it AOP, but rather on whether its mechanisms can be used to do AOP.

Imagine, if you will, Anne, a computer scientist working in isolation, who has invented a language exactly like AspectJ, except that she believes the purpose of the language is to insert debugging statements into conventional Java code. She's called the language "DebugJ," and everywhere AspectJ uses the word "aspect," she uses "debug." Her methodological explanations are all about temporarily inserting only debugging statements into code under development. Is DebugJ an AOP language?

Consider Betty, who believes she has invented a new aspect-oriented language called "AspectTran." AspectTran looks just like Fortran, except that "subroutine" has been replaced by the word "aspect." Betty explains that users should encode concerns separately in these aspect routines, and if a concern crosscuts another, they should invoke the aspect code with a CALL statement. Shared state between the aspect and the base routine is passed in parameters to the aspect call. Since Fortran is call-by-reference, one can even have an aspect change the value of a local variable! Betty is proud of how little she had to modify the Fortran compiler to create AspectTran. Is AspectTran an AOP language?

If this seems far-fetched, keep in mind how long it took to convince Ada aficionados that Ada83 was not an object-oriented language. Dahl, Myhrhaug, and Nygaard never mentioned that Simula 67 was an object-oriented language. Nevertheless, it's universally acclaimed as the first. Decide for yourself if Ada95 is an object-oriented language: One can do all the object-oriented things by using particular features in specific and non-obvious ways, but the term "object" is not part of the language's lexicon.

We have identified AOP with the ability to assert quantified statements over programs without explicit reference to these statements. This implies

AOP is not about OOP. OOP is a popular programming language technology. Most implementations of new language ideas are done in the context of OOP. The class hierarchy of OO systems is a convenient structure over which to quantify. However, "quantification" and "obliviousness"are independent of OO. Therefore, it is perfectly reasonable to develop AOP for functional or imperative languages. Work illustrating this point includes Coady et. al's AspectC for C [7] and Wand's ADJ/PROC for a first-order mini-language [41].

AOP is not useful for singletons. If one has an orthogonal concern that is about exactly one place in the original code, and that orthogonal concern will not propagate to other loci as the system evolves, it is probably a bad idea to use AOP for that concern. Just write a call to the aspect procedure into that place, or permute the source code in whatever way necessary to achieve the aspect. The cost to the software maintenance and evolution process by the existence of an additional aspect probably exceeds the benefit of using a singleton aspect.

AOP language designs ought to be more implicit. Our goal should be to minimize the degree to which programmers (particularly the programmers of the primary functionality) have to change their behavior to realize the benefits of AOP. It's a really nice bumper sticker to be able to say, "Just program like always, and we'll be able to add the aspects later." (And change policies later, and we'll painlessly transform the code for that, too.) Realizing that bumper sticker is a challenge to the developers of AOP.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net