AOP for PHP series learning

Have you ever heard of AOP (AspectOrientedProgramming? Although php does not seem to be widely used, AOP is widely used in enterprise-level development. I will take this article to introduce you to AOP in PHP. "> <LINKhref =" http://www.php100.com//statics/style/headfloor

 

Introduction

Have you ever heard of AOP (Aspect Oriented Programming? Although php does not seem to be widely used, AOP is widely used in enterprise-level development. I will take this article to introduce you to AOP in PHP.

This article mainly explains the concept of AOP.

What is AOP?

In application development, we often find that many functions are required. these functions need to be distributed across multiple points in the code, but these points are not actually related to the actual business. For example, before executing some special tasks, make sure that the user is in the login status. We call these special characters "cross-cutting concerns ", let's take a look at the definition of "cross-cutting concerns" through Wikipedia.

In computer science, "cross-cutting concerns" refers to "aspect (or direction) programming ". These relationships cannot be broken down from other systems (framework design or some implementations), so that code is duplicated, meaningful dependencies exist in the system, or both.

Now you should have a basic understanding of the "horizontal relationship". let's see what they are like in the code?

Assume that you are editing a blog site. You need to log on to the site, create a post, verify the post, edit the post, and so on. If you have not logged in, you should go directly to the login interface. To ensure that these actions are safe, any of the above operations must be validated. the code is as follows.

2. Class BlogPost extends CI_Controller
3. {
4. Public function createPost (){
5. If (! Authentication: checkAuthentication ()){
6. // Redirect to login
7. }
8. Else {
9. // Proceed
10. Messages: policyadmin ();
11. }
12. }
13.  
14. Public function approvePost (){
15. If (! Authentication: checkAuthentication ()){
16. // Redirect to login
17. }
18. Else {
19. // Proceed
20. }
21. }
22.  
23. Public function editPost (){
24. If (! Authentication: checkAuthentication ()){
25. // Redirect to login
26. }
27. Else {
28. // Proceed
29. }
30. }
31.  
32. Public function viewPost (){
33. //...
34. }
35. }

Looking at the code above, you will find that checkAuthentication () is called before each method, because these actions need to be performed after the user logs in. In addition, notifyAdmin () is used to identify whether it is an administrator account to create a new post. No, there are a lot of "repeated code", and the BlogPost class should only be responsible for managing posts. Authentication and identification should be separated. We violate the single responsibility principle ".

The single responsibility principle describes that each class should have only one single responsibility (task), and the entire responsibility should be encapsulated in one class. All services should be distributed in a balanced and rigorous manner.

So far, we can understand the meaning of AOP. The horizontal plane relationship is grouped into a class. We call this class "plane ". The process of separating the horizontal relationship from our core code is called Aspect Oriented Programming.

AOP terminology

There are many conditions specifically used to explain the features of AOP. Understanding these conditions will be the key to successfully integrating AOP into your project.

Aspect; Advice; Joinpoint; Pointcut

We have learned what Aspect is! Now let's take a look at what the other three conditions mean?

Advice (notification)

Advice is used to call Aspect (slice). as its name implies, Advice is used to define what to do and when to do it. In our previous example, checkAuthentication (what to do) is advice (notification), which should be called before (when) the code is executed in the specified method.

Joinpoint (Access Point)

Joinpoint is the location in the Advice application we created. Looking at the previous code, you will find that I have called several functions that are not directly associated with the business logic. In createPost (), for example, cross-cutting concerns should occur before the verification logic is executed and after the information is sent to the administrator. These may be access points.

In your application code, the access point can be placed anywhere. However, Advice can only be set in some points. this depends on your AOP framework. I will discuss it later.

Pointcut)

Point cutting defines a way to match a notification to certain access points. Although there is only one access point in our example, you can place thousands of access points in your application, and you do not need to apply notifications to all access points. You can bind some access points that you think are necessary to notifications.

Suppose we want to notify createPost (), approvePost () and editPost (), but there is no viewPost (). We use some method to bind these three methods to notifications. Then, we create an XML file that contains the section details. these details include some regular expressions matching the access point.

Conclusion: When a horizontal cut-in relationship exists in our application, we can create a cut-in that applies the notification function to some access points that choose to use point-cutting.

AOP notification type

The notification code can be displayed in many ways. As I mentioned earlier, these notification codes depend on the framework you are using, but for some types you need to be familiar with, please refer to the following:

Pre-notification; post-return notification; post-throw notification; peripheral notification

Pre-notification

Use notifications before some special points in your code-normally, you call a method.

So far, in order to simplify the concept and make you understand your code more quickly, I often write notifications to methods. However, in a real environment, notifications are often not written in methods. There should be an independent controller in which every method is included, and each method contains the function of AOP. This global controller runs throughout the system and is invisible to us.

2. Class PathController
3. {
4. Function controlPaths ($ className, $ funcName ){
5. Authentication: checkAuthentication ();
6. $ ClassObj = new $ className ();
7. $ ClassObj-> $ funcName ();
8. }
9. }

Suppose there is such a class, which is mainly used to show you what actually happened to this class. Assume that the controlPaths method is the global entry point in the application. you must use this method to access each method in the application. Before executing each method in the above method, we call the notification checkAuthentication (). -- This is the pre-notification.

Post-return notification

This notification is executed only once after the specified function is executed and the access point is returned. Consider the following code:

2. Class PathController
3. {
4. Function controlPaths ($ className, $ funcName ){
5. $ ClassObj = new $ className ();
6. $ ClassObj-> $ funcName ();
7. Database: closeConnection ();
8. }
9. }

Note that after the method is completed, the database resources are cleared. After a notification is returned, we call this notification.

Post-throw notification

If the function throws an exception during process execution, the application will notify you after the exception is thrown. After an exception is thrown, the notification becomes an error message.

2. Class PathController
3. {
4. Function controlPaths ($ className, $ funcName ){
5. Try {
6. $ ClassObj = new $ className ();
7. $ ClassObj-> $ funcName ();
8. }
9. Catch (Exception $ e ){
10. Error: reportError ();
11. }
12. }
13. }

Nearby notifications

The fourth type of notification is the peripheral notification, which is the combination of the forward notification and the return notification.

2. Class PathController
3. {
4. Function controlPaths ($ className, $ funcName ){
5. Logger: startLog ();
6. $ ClassObj = new $ className ();
7. $ ClassObj-> $ funcName ();
8. Logger: endLog ();
9. }
10. }