There have been many information about AspectJ, but most of them have begun to explain AspectJ syntax, this article explains Aspectj from another angle, the author emphasizes the design ideas and operational principles of AspectJ.
1. Sequence Aspect Oriented Programming (AOP) is a topic that has been relatively popular.
Aspectj is an implementation of AOP's Java language and has gained a wide concern of Java programmers.
For the specific information about AspectJ and AOP, find it from the following link:
Http://www.eclipse.org/aspectj/http://www.parc.com/research/csl/projects/aspectj/http://aosd.net/
There have been many materials that explain AspectJ, but most of them begin to begin the AspectJ syntax, then explain how to apply Aspectj, how to separate different aspects of the software development process (aspect) - log, session, authentication and authorization, transaction, and more.
The readers who have expired AspectJ see these information (or the syntax manual), you will feel aspectj some mysteries in ASPECTJ. They want to know how aspectj does this? What is aspectj work? Is ASPECTJ require special operating environments?
This article explains Aspectj from another angle. This article comes from the explanation of AspectJ's design ideas, and starts the principle, answering the above questions.
The main content of this article explains, according to the concept of the concept, the arrangement is as follows:
Aspectj is a code generation tool (Code Generator). 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 both code generation rules is amazing. Aspectj has its own grammatical compilation tool, compiled results are Java Class files, when running, ClassPath needs to include an JAR file (Runtime LIB) of AspectJ. Comparison of AspectJ and XDoclets. Comparison of AspectJ and EJB DESCRIPTOR.
The principle of this article is that only things that other materials have not been talked, other materials have been speaking, do not talk or slightly. To save online resources, save everyone's valuable time. J
2. Aspect Oriented Programming (AOP) This section briefly introduces the concept of AOP, explains why we need AOP.
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 whether the Account is a legitimate 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.
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.
The following chapter explains how EJB Descriptor, AspectJ, XDoclets can solve the problem of Separation of Aspects.
3. EJB DESCRIPTOR If we implement the above example with EJB, the Bank class can be implemented as a Stateless Session Bean.
In the code of Bank, only consider business logic, do not consider certification and transaction.
Certification and transactions are defined in EJB DESCRIPTOR, providing these aspects of implementation by EJB Container.
Let's take a look, how to use EJB Descriptor to describe the above example.
EJB Descriptor includes an ejb-jar.xml file. The EJB-JAR.XML file contains two parts, Enterprise-Beans, and Assembly-Descriptor section. The Enterprise-Beans section contains the definition of EJB - JNDI Name, EJB Home, Interface, Bean Class Path, etc .; Assembly-Descriptor section includes definition of configuration information - security roles, transaction control, etc.
The simulated EJB Descriptor corresponding to the above example is given below.
...
This article will tell Separation of Aspects in context using aspectj.
The reader can compare the correspondence between the AspectJ syntax and the EJB DESCRIPTOR definition.
Both provide class names, method name matching rules, which can map classes to Aspect (aspects) such as authentication, transaction.
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.
How to verify this? You can download install aspectj to http://www.eclipse.org/aspectj/, compile the SAMPLE inside, and compile the compilation result, you can see the code that aspetj automatically generated.
We see that aspectj is a code automatic generation tool. You write a universal code, such as the authentication code, transaction code, then define a set of code generation rules according to the AspectJ syntax (Aspect definition), aspectj will help you distribute this general code into the corresponding code. Go, simple and fast, countlessness.
Done, a famous compiler generating tool - Java Compiler Compiler (JAVACC), which also uses very similar code generation mechanism. JavaCC allows you to add your own Java code in your own grammatical definition rule file to handle various syntax elements read. Aspectj makes your code more streamlined, more structure. Aspectj's benefits, I will not say much, there are many wonderful articles on the Internet to explore the various purposes of AspectJ.
Here is a well-known code automatic generator - xdoclet, and comparison between EJB Descriptor, Aspectj.
5. XDoclets We know that doclets are used to generate javadoc, XDoclets are Doclet extensions, but also generate Javado, but also generate source code and configuration information.
The working principle of Doclet and XDoclet is to process tags in the comments in the source code to generate appropriate information. These tags begin with @, you can define TAGs and to process TAG to generate custom information.
(Here, Apache Maven Project.maven is a Project Build Tool. Use maven-managed projects, can generate Javadoc and XREF.xref at the same time, Source Code Cross Reference.)
JBoss uses xDoclets to automatically generate EJB HOME and EJB Object Interface source files for EJBs, and EJB Descriptor files.
See a open source project called Barter on the SourceForge.NET, generate the AspectJ code using XDoclets for class methods.
Please note that both EJB Descriptor and Aspectj are managed to manage all aspects, while xDoclet is to process all kinds of TAGs spread in the source code.
XDoclets are generating EJB Descriptor and AspectJ and other applications, and it is based on an old saying in China - the budget necessity, and theirs will be divided.
6. Summarizing the emergence of open source projects, breaking the number of barriers in the field of software technology, and promoting the current period of software technology process.
At the same time, some new names, new concepts are also endless, dazzling, and it is easy. In fact, a lot of things are refined to change the soup, we understand the application of these new technologies, to seize the nature, to break the superstition, and break any artificial mystery.
For example, now the hottest concept, "Web Service", and "Grid Computation", which is based on the original development of various technologies. Media and technical articles should not be artificially created by any mystery.
The authority of the Internet era is not to say, but it is made.
In addition, surrounding some promising new technologies, there will always have a large number of "quick entry manual", some are simply translating the technology to help documents, and there is difficult place to translate, everyone understands Very detailed, detailed to no need. This is a large number of technical articles in the technical articles because of the views of the market demand.
The author's expectation is that it is not superstitious and will never repeat. And try to introduce a clean, unused nonsense. The author looks forward to seeing the refuters and criticism of blood.
