Aspect-oriented Programming - Motivation and Basic Concepts

Motivation and Basic Concepts

Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception { if (fromAcc.getBalance < amount) { throw new InsufficientFundsException; } fromAcc.withdraw(amount); toAcc.deposit(amount); }

However, this transfer method overlooks certain considerations that a deployed application would require: it lacks security checks to verify that the current user has the authorization to perform this operation; a database transaction should encapsulate the operation in order to prevent accidental data loss; for diagnostics, the operation should be logged to the system log, etc.

A version with all those new concerns, for the sake of example, could look somewhat like this:

void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) throws Exception { logger.info("Transferring money..."); if (! checkUserPermission(user)){ logger.info("User has no permission."); throw new UnauthorizedUserException; } if (fromAcc.getBalance < amount) { logger.info("Insufficient funds, sorry."); throw new InsufficientFundsException; } fromAcc.withdraw(amount); toAcc.deposit(amount); //get database connection //save transactions logger.info("Successful transaction."); }

In this 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.

Now 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.

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) when one can access a bank account, 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.

So for the above example implementing logging in an aspect:

aspect Logger { void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) { logger.info("Transferring money..."); } void Bank.getMoneyBack(User user, int transactionId, Logger logger) { logger.info("User requested money back."); } // other crosscutting code... }

One can think of AOP 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) or do not want to change the function in production code (debugging).