In computer science, a concern is a particular set of behaviors needed by a

computer program, the conceptual sections. A concern can be as general as

database interaction or as specific as performing a calculation, depending on the
level of conversation between developers and the program being discussed.

Usually these needs can be separated from each other into logical sections and
allow the program to be modularized. Edsger W. Dijkstra coined the term
"separation of concerns" to describe the mentality behind this modularization,
which allows the programmer to reduce the complexity of the system being
designed. Two different concerns that intermingle in the same section of code are
called "highly coupled". Sometimes the chosen module divisions do not allow for
one concern to be completely separated from another, resulting in cross-cutting
concerns. The various programming paradigms address the issue of cross-cutting
concerns to different degrees. Data logging is a common cross-cutting concern,
being used in many other parts of the program other than the particular module(s)
that actually log the data. Since changes to the logging code can affect other
sections, it could introduce bugs in the operation of the program.

In computer science, an aspect is a part of a program that cross-cuts its core

concerns, therefore violating its separation of concerns. It is a feature linked to
many parts of a program, but which is not necessarily the primary function of the
program. 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
aspect-oriented software development (AOSD), of which the aspect-oriented
programming (AOP) paradigm is the most widely employed.

For example, consider a banking application with a conceptually very simple

method for transferring an amount from one account to another:[2]

void transfer(Account fromAcc, Account toAcc, int amount) {

if (fromAcc.getBalance() < amount) {
throw new InsufficientFundsException();
}

fromAcc.withdraw(amount);
toAcc.deposit(amount);
}
However, this transfer method overlooks certain considerations that would be
necessary for a deployed application. It requires security checks to verify that the
current user has the authorization to perform this operation. The operation should
be in a database transaction in order to prevent accidental data loss. For
diagnostics, the operation should be logged to the system log. And so on. A
simplified version with all those new concerns would look somewhat like this:

void transfer(Account fromAccount, Account toAccount, int amount) throws

Exception {
if (!getCurrentUser().canPerform(OP_TRANSFER)) {
throw new SecurityException();
}

if (amount < 0) {
throw new NegativeTransferException();
}

if (fromAccount.getBalance() < amount) {

 throw new InsufficientFundsException();
}

Transaction tx = database.newTransaction();
try {
fromAccount.withdraw(amount);
toAccount.deposit(amount);

tx.commit();
systemLog.logOperation(OP_TRANSFER, fromAccount, toAccount, amount);
}
catch(Exception e) {
tx.rollback();
throw e;
}
}
In the previous example other interests have become tangled with the basic
functionality (sometimes called the business logic concern). Transactions, security,
and logging all exemplify cross-cutting concerns.

Also consider what happens if we suddenly need to change (for example) the
security considerations for the application. In the program's current version,
security-related operations appear scattered across numerous methods, and such a
change would require a major effort.

Therefore, we find that the cross-cutting concerns do not get properly encapsulated
in their own modules. This increases the system complexity and makes evolution
considerably more difficult.

AOP attempts to solve this problem by allowing the programmer to express cross-
cutting concerns in stand-alone modules called aspects. Aspects can contain advice
(code joined to specified points in the program) and inter-type declarations
(structural members added to other classes). For example, a security module can
include advice that performs a security check before accessing a bank account. The
pointcut defines the times (join points) that a bank account can be accessed, and
the code in the advice body defines how the security check is implemented. That
way, both the check and the places can be maintained in one place. Further, a good
pointcut can anticipate later program changes, so if another developer creates a
new method to access the bank account, the advice will apply to the new method
when it executes.

AOP can be thought of as a debugging tool or as a user level tool. Advice should be
reserved for the cases where you cannot get the function changed (user level) (from
Emacs Documentation) or do not want to change the function in production code
(debugging).
 Terminology
 A join point is a well-defined p
 A pointcut is a group of join po
 Advice is code that is executed
 Introduction modifies the mem
relationships between classes
 An aspect is a module for hand
concerns
 Aspects are defined in terms of p
introduction
 Aspects are reusable and inherita
 Each of these terms will be dis