What is ASPECTJ?

Reprinted from: http://www.cnblogs.com/sunwke/articles/2568875.html

There is a lot of information on the Internet, but most of it starts with explaining the AspectJ grammar, then explains how to apply the AspectJ, how to separate different aspects of the software development process (Aspect)--log,session,authentication and AspectJ. Authorization,transaction, wait.

The first contact with AspectJ readers to see this material (or grammar manual), will feel AspectJ somewhat mysterious. They want to know how AspectJ did it? How does the AspectJ work? Does AspectJ require a special operating environment?

This article from another angle explains AspectJ, this article starts from the explanation AspectJ design thought, the operation principle, answers above question.

This article explains the main content, according to the concept of the importance of the following arrangement:

1. The AspectJ is a code-generation tool (Generator).
2. The AspectJ syntax is the syntax used to define code generation rules. If you have used Java Compiler Compiler (JavaCC), you will find that the concept of code generation rules is strikingly similar.
3. AspectJ has its own syntax compiler tool, the result of compiling is Java Class file, when running, classpath need to contain AspectJ of a jar file (runtime Lib).

Section briefly introduces the concept of AOP and explains why we need AOP.

AOP is a complement to Object oriented programming (OOP).

OOP can solve the problem of object's data and encapsulation well, but it can't solve the problem of separation of Aspect ("aspect") well. The following are examples of specific.

For example, we have a bank class. Bank has two methods, deposit (save) and withdraw (take money).

The classes and methods are defined as follows:

Code 2.1 Bank.java class bank{public float deposit (accountinfo accounts, float money) { //Add money to account, return Current amount of money in account} public float withdraw (accountinfo accounts, float money) {//Reduce the amount of the account, return the amount of money withdrawn}

These two methods involve the user's account funds and other important information, must be very careful, so after writing the above business logic, the project leader also put forward new requirements-to the Bank class each important method plus security authentication characteristics.

Therefore, we have to add the security authentication code in the above two methods separately.

The classes and methods are defined as follows: (the newly added code is marked with a different background)

Code 2.2 Bank.java class bank{public float deposit (accountinfo account, float-money) { //Verify that it is a legitimate user c4/>//increase the amount of the account, return the current amount of money in the account} The public float withdraw (accountinfo accounts, float money) { //Verify accounts are valid //Reduce the amount of money in account accounts and return the amount of money taken out}

Both methods need to operate the database, in order to maintain the integrity of the data, the project leader has put forward new requirements-to the Bank class of each operational database method plus transaction control.

Therefore, we have to add the security authentication code in the above two methods separately.

The classes and methods are defined as follows:

Code 2.3 Bank.java class bank{public float deposit (accountinfo account, float-money) { //Verify that it is a legitimate user c4/>//Begin Transaction//Increase the amount of account in Account , return the current amount of money //End Transaction } public float withdraw ( AccountInfo accounts, float money) { //Verify that the account is a legitimate user//Begin Transaction//Reduce the amount of money in the deposit book and return the amount of money taken out //End Transaction }

We see that these repetitive code, unrelated to business logic, is pervasive throughout the program. The actual projects involved in the classes and functions, far more than two. How to solve this problem?

Let's first look at whether OOP solves this problem.

Using the Template pattern of design pattern, we can pull out a frame and change the entire design structure of the example above.

The classes and methods are defined as follows:

Code 2.4 Base.java abstract class base{public float Importantmethod (accountinfo account, float money) { // Verify that the account is a legitimate user //Begin Transaction Float result = yourbusiness (client, Money) //End Transaction return result; } protected abstract Float yourbusiness (accountinfo account, float money); }; Code 2.5 Bankdeposit.java class Bankdeposit extends base{ protected float yourbusiness (accountinfo account, Float money) {//increase the amount of the account and return the current amount in the account} }; Code 2.6 Bankwithdraw.java class Bankwithdraw extends base{ protected float yourbusiness (accountinfo account , float money) {//Reduce the amount of money in account accounts and return the amount of money taken out}

Here we use a very reluctant method to achieve the reuse of authentication and transaction code. Moreover, the intentional reader may notice that this approach is premised on forcing all methods to follow the same signature.

If there is a transfer method transfer (AccountInfo giver, accountinfo receiver, float money), because transfer method signature differs from Yourbusiness's sign Ature, this method cannot use the above framework.

The authentication, transaction, etc. mentioned in this example is the Aspect that AOP cares about.

AOP is a solution to this problem. The purpose of AOP is--separation of aspects (or separation of concerns).

With AspectJ, we do not have to make any changes to the original code to provide different Aspect (aspects) for the code-for example, authentication, transactions, etc.

We only need to provide two different aspect--certified Aspect and Transaction Aspect.

Code 4.1 authaspect.java aspect authaspect{ pointcut bankmethods (): Execution (* bank.deposit (...)) | | Execution (* Bank withdraw (...)); Object around (): Bankmethods () { //Verify that account is a legitimate user return proceed (); } }; Code 4.2 transactionaspect.java aspect transactionaspect{ pointcut bankmethods (): Execution (* bank.deposit ( ... )) || Execution (* Bank withdraw (...)); Object Around (): Bankmethods () { //Begin Transaction Object result = proceed (); End Transaction return result;

If you do not understand this code for the time being, there is no relationship, but later on, these aspect definitions simply define some code generation rules.

We compile the bank file with the AspectJ compiler and the file containing the aspect, and the result is a bank class with security authentication and transaction processing. The compiled bank class calls the AspectJ runtime lib, so if you want to run the bank class, you need to set AspectJ runtime lib in your classpath.

Let's take a look at what the AspectJ compiler did for us.

2. First, AspectJ all the file names from the file list, and then reads the files for analysis.
4. AspectJ found that some files contain the definition of aspect, in this case, the definition of Authaspect and transactionaspect, and these aspect are code generation rules.
6. AspectJ According to these aspect code generation rules, modify add your source code. In this example, the Add Bank file is modified.
8. AspectJ read the definition of authaspect and found a pointcut--bankmethods (); This pointcut is defined as execution (* bank.deposit (...)) | | Execution (* Bank withdraw (...)), which represents all the execution points for the deposit and withdraw methods of the Bank class.
10. AspectJ continue to read the definition of Authaspect, found a around (), which is called Advice in AspectJ, I do not understand why this name, but it doesn't matter, we just need to know what it is to do. Advice allows you to add additional code before or after a call to a method of a class. The "//Verify account is a legitimate user" section of around () in Code 4.1 shows the code to be added. Where does this piece of code add to? Around () followed by a pointcut--bankmethods (). According to this POINTCUT,ASPECTJ will add this code to the Bank.deposit and Bank.withdraw two methods before the execution. The effect is as shown in Code 2.2.
12. AspectJ read the definition of Transactionaspect, as in step (4), found a pointcut--bankmethods ().
14. AspectJ continues to read the definition of Authaspect and discovers a around (). This time AspectJ the "Begin Transaction" and "End Transaction" Two pieces of code added to the Bank.deposit and Bank. Withdraw two methods before and after the execution. The effect is as shown in Code 2.3.

How do I verify this? You can go to http://www.eclipse.org/aspectj/to download the installation ASPECTJ, compile the Sample inside, compile the results to decompile, you can see the ASPETJ automatically generated code.

As we can see, AspectJ is an automatic code generation tool. You write a common code, such as authentication code, transaction code, and then define a set of code generation rules based on AspectJ syntax (aspect definition), AspectJ will help you automatically distribute this generic code into the corresponding code, simple and quick.

Reprinted from: http://www.cnblogs.com/sunwke/articles/2568875.html

What is ASPECTJ?