Aspect Oriented Programming

 In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method. Any AOP language has some crosscutting expressions that encapsulate the concern in one place.

The difference between AOP languages lies in the power, safety, and usability of the constructs provided. E.g., interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches).

An aspect can also make binary-compatible structural changes to other classes, like adding members or parents. In computer science, an aspect is a part of a program that cross-cuts its core concerns, therefore violating its separation of concerns. For example, logging code can cross-cut many modules, yet the aspect of logging should be separate from the functional concerns of the module it cross-cuts. Isolating such aspects as logging and persistence from business logic is the aim of the aspect-oriented software development, of which aspect-oriented programming paradigm is the most established area.

Aspect-orientation is not limited to programming since it is useful to identify, analyse, trace and modularise concerns (e.g., PREview) through requirements elicitation, specification and design. Aspects can be multi-dimensional by allowing both functional and non-functional behaviour to cross cut any other concerns, instead of just mapping non-functional concerns to functional requirements.