The Case for Aspects


We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day. . . . But nothing is gainedon the contraryby tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns."

EDSGER DIJKSTRA[1]

[1] 1 "On the role of scientific thought," EWD. 477, 30 August 1974, Neuen, The Netherlands.

Aspect-oriented programming ( P)[2] was introduced to provide a solution to the scattering and tangling described above. It is often described as liberating developers from the hegemony of the dominant decomposition.[3] Simply put, this means that whichever modularity you choose (objects, functions, etc.) will at some point impose unwanted constraints on your design. In the object-oriented case, the dominant decomposition is the modularity of classes, and methods. The hegemony refers to the fact that when pinned to object-orientation, developers are forced to make design decisions that lead to scattering and tangling. In some cases, developers must be able to break out of that modularity and design code that crosscuts an object model.

[2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. "Aspect-Oriented Programming." In ECOOP'97Object-Oriented Programming, 11th European Conference, LNCS 1241, pp. 220242, 1997.

[3] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr., "N Degrees of Separation: Multidimensional Separation of Concerns," Proc. ICSE 99, IEEE, Los Angeles, May 1999, ACM press, pp. 107119.

AOP allows a developer to program those crosscutting portions of a system separately from any of these structural entities. Even though in its infancy, P has proven to be of great use in modularizing source code and has provided a wide spectrum of benefits, from performance enhancement to more evolvable code. Aspect-oriented languages provide support for programming such crosscutting concerns, or aspects, in one place and then automatically propagating the behavior to the many appropriate points of execution in the code. In this way, aspects allow a developer to specify behavior that overlays an existing class model.

However, aspects certainly should not be used as the hammer for every nail. Just as considering when to use inheritance, it is important to consider when an aspect is an appropriate choice for some functionality. Nonetheless, aspect-orientation has been shown, when used properly and appropriately, to transform necessarily hairy code into something manageable and reasonable.



Aspect-Oriented Analysis and Design(c) The Theme Approach
Aspect-Oriented Analysis and Design: The Theme Approach
ISBN: 0321246748
EAN: 2147483647
Year: 2006
Pages: 109

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