Aspect-oriented programming

For example, a telecommunications application might have a core concern of routing calls, while code for timing and billing those calls would crosscut the whole object hierarchy. AOP aims to separate the billing concerns from the core concern. It moves code not related to solving the domain problem from the business logic into a separate module. The application code no longer contains pieces of crosscutting concerns scattered across modules; instead, programmers maintain crosscutting concerns in aspects; this makes it easier to maintain both core and crosscutting concerns.

Any program has principled points (join points) where programmers can identify and modify the program semantics. In AOP, programmers specify join points using a language feature called a pointcut, and specify the behavior to join those points by using advice such as methods or functionss. Some variants of AOP allow programmers to extend the types in the system. These features enable aspects to implement behavior for concerns that crosscut the core concern of the application.

AOP Steps

The steps to successful aspect-oriented programming comprise:

1. The designer defines and separates the concerns, core and crosscutting.
2. The developer writes independent modules to implement them.
3. The AOP system combines the modules (AOP calls this "weaving").

AspectJ: an AOP language

AspectJ is a famous AOP language based on Java and developed at Xerox PARC by Chris Maeda, who originally coined the term "aspect-oriented programming" (no one remembers exactly when). Gregor Kiczales coined the term "cross-cutting". The Xerox group's work was later integrated into the Eclipse Foundation's Eclipse Java IDE, which helped AspectJ become one of the most widely-known aspect-oriented languagess.

AOP and other programming paradigms

Aspects emerged out of object-oriented programming and have functionality similar to meta-object protocols. Aspects relate closely to programming concepts like subjects, mixins, and delegation.

Mathematically, aspects are a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, AOP enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension, rather than an independent paradigm. Friedrich Steimann, for example, has proposed such a view.

But AOP proponents promote it as an external package shippable along with some application. For example, if a program itself has no support for security, an AOP package can serve as a modular extension to the application, providing security.

Problems for AOP

One of the greatest problems for AOP is debugging. While at the syntactic level AOP program code appears separate, at run-time it is not. Concern-weaving can become unpredictable if it is not specified which aspect should dominate. Designers have considered alternative ways to achieve separation of code, such as C#'s partial types. However, such approaches lack a quantification mechanism enabling programmers to reach several join points of the code with one declarative statement.

Implementations