AOP is supplemented by Object Oriented Programming (OOP).
OOP can solve the problem of data and packages of objects well, but it is not good to solve the problem of aspect ("aspect"). The following example will be specifically described.
For example, we have a Bank (Bank) class. Bank has two methods, deposits and withdraw (money).
The definitions of classes and methods are as follows:
Code 2.1 Bank.java
Class bank {
Public Float Deposit (Accountinfo Account, Float Money) {
/ / Increase the amount of money in the Account account, return to the current amount of money in the account
}
Public Float Withdraw (Accountinfo Account, Float Money) {
/ / Reduce the amount of money of the Account account, return the amount of money taken out
}
}
These two methods involve important information such as users' account funds, must be very careful, so after writing the above business logic, the project leader has put forward new requirements - adding every important method for the Bank class. Authentication characteristics.
Thus, we have to add a secure authentication code to the two methods above.
The definitions of classes and methods are as follows: (The newly added code is marked with different backgrounds)
Code 2.2 Bank.java
Class bank {
Public Float Deposit (Accountinfo Account, Float Money) {
// Verify whether the Account is a legitimate user
/ / Increase the amount of money in the Account account, return to the current amount of money in the account
}
Public Float Withdraw (Accountinfo Account, Float Money) {
// Verify whether the Account is a legitimate user
/ / Reduce the amount of money of the Account account, return the amount of money taken out
}
}
Both methods need to operate the database. In order to maintain data integrity, the project leader has proposed a new requirement - the method for each operational database of the Bank class plus transaction control.
Thus, we have to add a secure authentication code to the two methods above.
The definitions of classes and methods are as follows: (The newly added code is marked with different backgrounds)
Code 2.3 Bank.java
Class bank {
Public Float Deposit (Accountinfo Account, Float Money) {
// Verify whether the Account is a legitimate user
// begin Transaction
/ / Increase the amount of money in the Account account, return to the current amount of money in the account
// end transaction
}
Public Float Withdraw (Accountinfo Account, Float Money) {
// Verify whether the Account is a legitimate user
// begin Transaction
/ / Reduce the amount of money of the Account account, return the amount of money taken out
// end transaction
}
}
We see that these repetitive code that are unrelated to commercial logic is spread throughout the program. The classes and functions involved in the actual engineering project are far more than two. How to solve this problem?
Let's take a look at whether the OOP can solve this problem.
We use Design Pattern's Template Pattern, you can take out a framework to change the entire design structure of the above example.
The definitions of classes and methods are as follows:
Code 2.4 Base.java
Abstract class base {
Public Float ImportantMethod (AccountInfo Account, Float Money) {// Verify that Account is legal user
// begin Transaction
Float Result = Yourbusiness (Account, 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 money in the Account account, return to the current amount of money in the account
}
}
Code 2.6 Bankwithdraw.java
Class Bankwithdraw Extends Base {
Protected float yourbusiness (Accountinfo Account, Float Money) {
/ / Reduce the amount of money of the Account account, return the amount of money taken out
}
}
Here we use a very reluctant way to realize the reuse of certification and transaction code. Moreover, the innocerable readers may notice that the premise of this method is that it is forced that all methods comply with the same Signature. (Mandatory is annoying, think about EJB, it is a Nightmare for J2EE)
If there is a transfer method Transfer (AccountInfo Giver, AccountInfo Receiver, Float Money), due to Signature of the Transfer method is different from YourBusiness, this method cannot use the above frame.
The authentication, transaction, etc. mentioned in this example is the ASPECT that AOP is concerned.
AOP is to solve this problem. The purpose of AOP is - Separation of Aspects.
4. AspectJ This section Let's take a look at how aspectj implements Separation of Aspects in the above example.
With AspectJ, we don't have to make any modifications to the original code, you can provide different aspect (aspects) for the code - such as certification, transaction, etc.
We only need to provide two different aspect - authentication aspect and transaction aspect.
Code 4.1 Authaspect.java
Aspect authaspect {
Pointcut BankMethods (): Execution (* Bank.Deposit (...) || Execution (* Bank. withdraw (...);
Object arround (): BankMethods () {
// Verify whether the Account is a legitimate user
Return proceed ();
}
}
Code 4.2 TransactionAspect.java
Aspect transactionaspect {
Pointcut BankMethods (): Execution (* Bank.Deposit (...) || Execution (* Bank. withdraw (...);
Object arround (): BankMethods () {
// begin Transaction
Object result = proceed ();
// end transaction
Return Result;
}
}
If you can't understand this code for a while, there is no relationship, which will tell, these aspect definitions, but some code generation rules are defined. We compile Bank files with AspectJ compilers and this file containing Aspect, the result is a Bank class with secure authentication and transaction processing. The Bank class compiled is called Aspectj Runtime Lib, so if you want to run this Bank class, you need to set the AspectJ runtime lib in your classpath.
Let's take a look, what is the AspectJ compiler done for us.
First, AspectJ removes all filenames from the file list and read these files to analyze. AspectJ discovers that some files contain aspect definitions, in this example, the definition of Authaspect and TransactionAspect; these aspect is code generation rules. AspectJ generates rules according to these aspect code, modify the addition of your source code. In this example, it is a modification to add a Bank file. Aspectj read the definition of Authaspect and discovered a PointCut - BankMethods (); this PointCut definition is Execution (* Bank.Deposit (...)) || Execution (* Bank. Withdraw (...), indicating all Bank classes The execution point of the deposit and the Withdraw method. Aspectj continues to read the definition of Authaspect, found an around (), which is called Advice in Aspectj, I don't understand why this name is called, but it doesn't matter, we just know what it is doing. Advice allows you to add additional code before or after the call to a class method. The "// Verify Account is the Legal User" section in the code shown in Code 4.1, is the code to join. Where is this code you want? Around () follows a Pointcut - BankMethods (). According to this POINTCUT, Aspectj will join this code before the execution of the Bank.Deposit and Bank.withDraw. The effect of achieving is as shown in Code 2.2. AspectJ reads the definition of Transactionaspect, like step (4), found a PointCut - BankMethods (). Aspectj continues to read the definition of Authaspect and discover an Around (). This time AspectJ adds "Begin Transaction" and "End Transaction" two-way code to Bank.Deposit and Bank. Withdraw two methods. The effect of achieving is as shown in Code 2.3.
Comparison:
Aspectj is a centralized Aspects to manage, while XDoclet's idea is to process all kinds of Tags spread in source code.
For a long time, the long-term
