Aspect-Oriented Programming-separation of concerns

The most important concept of Aspect-Oriented Programming is "separation of concerns )".

I have never understood this concept. Today, I recalled Python and Ruby programming knowledge. Make a mark.

1. Start with repeated code.

Code is often written, repeated code is often written, the seemingly useless repeated code is often written, and the seemingly useless code has to be written.

In application system programming, we often add code for permission check in the Login-related methods, such:

1 public void OnLogin ()
2 {
3 if (Session ["Privilege"]! = "Admin ")
4 {
5 throw ApplicationException ("Unauthenticated ");
6 return;
7}
8 // Other Codes
9}

Code similar to this will appear on every page.

From the code structure, we can see that the OnLogin method basically consists of the following two aspects:

// A. Execute the permission check-repeated

// B. Execute other transactions.

For "A, execute permission check", this part of code is the same on every page and will not be changed-this part of code is required for normal permission check.

What should I do?

The most common method is "encapsulation method", which encapsulates the code that executes the permission check into a static method call, as shown in the following figure:

1 public void OnLogin ()
2 {
3 Common. CheckPrivilege ("Admin ");
4 // Other Codes
5}

This has begun to encapsulate the focus, but it is still a little worse: we need to separate it-in different methods, in different files.

In fact, the most ideal method for client code is:

1 [PrivilegeCheck ("Admin")]
2 public void OnLogin ()
3 {
4 // Other Codes
5}

Using Custom attributes (Custom Attibutes), we separate the code for "permission check execution" from the code for "execute other tasks", not only logically, physically separated (two files ). More importantly, we can dynamically build a code through (Template), and bond the two pieces of code at Runtime. This gives you the maximum flexibility and simplicity of your code.

 

2. What is the aspect/focus.

I have read an article saying that AOP is an upgrade of OOP. At that time, I didn't understand AOP, and I didn't know what it was about. Now I seem to understand it.

To separate concerns, we must first find the concerns. For example, the "permission check" section in the previous example. Between the "permission check" and "other tasks", we construct a plane that separates the above two concerns.

As I know, understanding encapsulation and successful implementation of encapsulation are the first step to implement AOP. The second is to find a proper aspect.

3. A small AOP example.

To deepen my understanding, I used the idea of AOP to write sample code for permission check during login.

Small AOP example

4. What can we do with AOP?

We often see the application of AOP in various frameworks. In fact, you can use AOP to separate injection points. For example, to execute Logging and execute database Transaction, a large amount of repetitive and writable code is required, which is also a common application of AOP.

But everything has advantages and disadvantages. AOP undoubtedly increases the difficulty of debugging, understanding and implementation, and increases complexity. Before using AOP, we still need to consider whether or not we need AOP. We don't have to worry about AOP. we can reconstruct it when necessary.