AspectOrientedProgramming

Aspect-Oriented programming (AOP) addresses the problem of encapsulating cross-cutting concerns, which cut across program modules. In many systems, module boundaries are determined by the dominant decomposition, but participate in other concerns. The code for these other concerns is tangled within and scattered throughout the dominant modules, making them difficult to understand and change.
Here are some typical examples of crosscutting concerns:

• error checking and handling
• synchronization
• context-sensitive behavior
• performance optimizations
• monitoring and logging
• debugging support
• multi-object protocols

AOP encapsulates crosscutting concerns into a single program module called an aspect, which can add behavior to a program and verify or change its static structure. The aspect specifies join points in the running program using pointcuts, and permits advice code to run around the join point, to join the advice behavior to the program semantics. The aspect can also declare members and supertypes of other classes if the declarations are type-safe, binary-compatible and respect access rules. The combination of advice and inter-type declarations enables one to implement the correct associations and behaviors for many objects in one aspect.

Aspect-oriented programming is descended from MethodCombination , which was first introduced in Flavors and New Flavors (H. I. Cannon. Flavors: A non-hierarchical approach to object-oriented programming. Symbolics, Inc., 1982), based on an earlier paper by Howard Cannon at MIT (H. I. Cannon: Flavors, Technical Report, MIT Artificial Intelligence Laboratory, Cambridge (Mass.), 1980) and adapted by CommonLoops and CommonLisp (CLOS).

A similar mechanism for tracing Lisp functions was introduced in InterLisp in the mid-1970s (Teitelman, Warren, et al. InterLISP Reference Manual. Xerox Palo Alto Research Center, Palo Alto, California, 1974. First revision).

Aspects are also related to Mixins (Mixin-based Inheritance, Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications; Proceedings of the European Conference on Object-Oriented Programming, 1990) and Simula's and Beta's notions of (virtual) patterns and the Inner operator.

AOP implementations differ in how they specify and integrate aspects. AspectJ is an implementation of aspect-oriented programming for Java. AspectC is an implementation for C++. There is actually a big community of software developers and academics very interested in Aspect-Oriented Programming. Besides AspectJ, there are also other projects, like AspectWerkz and Nanning, making quite a lot of progress in the area.

AOP is growing from a programming perspective into a comprehensive methodology for AOSD (aspect-oriented software development). The main site for AOSD is http://aosd.net, which lists the current technology and research and hosts a discussion list.

See also

• http://aopalliance.sourceforge.net/
• http://joyaop.sourceforge.net/
• https://dynaop.dev.java.net/
• https://naop.dev.java.net/
• http://www.springframework.org/
• http://www.jboss.org/products/aop
• Implement your own proxy-based AOP framework
• http://www.aopworld.com/

Discussion about AspectOrientedProgramming

rpg: AspectC also seems to be the name of AOP for C. Can someone disambiguate this?

VW: It seems to me that AOP could be very dangerous. By writing aspects that alter the flow of code, one can no longer just read regular code and assume that it does what it says it does. This seems much worse than 'goto' to me.

* An Orthogonal aspect do not alter or interact with the initial flow of code.

wes: It's true that AOP tools need to show what's happening, but if/since aspects are modular, they should be non-invasive, and one should be able to reason about modules separately. The alternative to AOP is scattered spaghetti, where code for a concern is scattered throughout a number of modules, and a particular module contains a lot of little snippets for different concerns - explicit, but messy! (Also, I made some suggested changes to the summary; please revise as warranted.)