The AOP of PHP series learning

Introduced

Have you ever heard of AOP (Aspect oriented programming)? Although there seems to be no excessive use of PHP, AOP is widely used in enterprise-wide development. I will take this article to introduce you to the AOP of PHP.

This article mainly explains the concept of AOP.

What is AOP?

In application development, we often find that a lot of functionality needs to be scattered across multiple points in the code, but these points actually have nothing to do with the actual business. For example, to make sure that the user is in a login state before performing some special tasks, we call these special characters "cross-cutting concerns", and let's get to Know "cross-cutting concerns" through Wikipedia. Definition of (transverse relationship).

In computer science, "cross-cutting concerns" refers to "slice (or direction) programming". These relationships cannot be well decomposed from other systems (framework design or some implementations) so that there is a duplication of code, a meaningful dependency in the system, or both.

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

Suppose a scenario where you are an editor of a blog site. You need to login to the site, and then create posts, verify posts, edit posts, and so on. If you do not log in, then you should go directly to the login interface. In order to ensure that these behaviors are safe, any of the above actions will need to be validated with the following code.

2. 		<?php

4. Class Blogpost extends Ci_controller
6. {
8. Public Function Createpost () {
10. if (! Authentication::checkauthentication ()) {
12. Redirect to login
14. }
16. else {
18. Proceed
20. Messages::notifyadmin ();
22. }
24. }
28. Public Function Approvepost () {
30. if (! Authentication::checkauthentication ()) {
32. Redirect to login
34. }
36. else {
38. Proceed
40. }
42. }
46. Public Function Editpost () {
48. if (! Authentication::checkauthentication ()) {
50. Redirect to login
52. }
54. else {
56. Proceed
58. }
60. }
64. Public Function Viewpost () {
66. // ...
68. }
70. }

Looking at the code above, you will find that checkauthentication () is invoked before each method, because these behaviors require the user to log in before they can proceed. There is also the notifyadmin () to identify whether it is an administrator account in order to create a new post. See no, there are a lot of "duplicate code", and the blogpost class should only be responsible for managing posts. Authentication and identification should be separate. We violate the principle of sole responsibility.

The principle of single responsibility tells you that each class should have only a single responsibility (task), and that the entire responsibility should be encapsulated in a class. All services should be distributed in a rigorous and balanced way.

So far, we have been able to understand the meaning of AOP. The cross section relationship is put into a class by a group, and we call this class "slice". The process of separating the cross section relationship from our core code is called Aspect oriented programming.

AOP Professional Terminology

There are many conditions that are specifically designed to explain the characteristics of AOP. Understanding these conditions will be the key to your successful integration of AOP into your project

Aspect;advice;joinpoint;pointcut

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

Advice (notice)

Advice is used to invoke aspect (slice), as its name implies, advice to define what to do and when to do it. In our previous example, checkauthentication (what to Do) is advice (notification), in the specified method it should be called before the execution of the code (what time).

Joinpoint (Access point)

Joinpoint is where we create the advice application. Looking at the previous code, you'll notice that I've called several features that are not directly related to the business logic. In Createpost (), for example, cross-cutting concerns should occur before the validation logic is performed and after the message is sent to the administrator. These can all be access points.

In your application code, the access point can be placed in any location. But advice can only be arranged at certain points, depending on your AOP framework, which I will discuss later.

Pointcut (Point Cutting)

Point cutting defines a way to match notifications to certain access points. Although there are only a couple of access points 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 the notification.

Suppose we want to notify Createpost (), Approvepost () and Editpost (), but now there is no viewpost (). We use some method to bind these three methods to the notification. Then we create an XML file that contains the detail of the slices, which contains some regular expressions that match the access point.

Summary: When there is a horizontal cut in our application, we can create a slice, which applies the notification function on some access points that choose to use point cutting.

AOP Notification Type

Notification code we can perform in many ways. As I mentioned earlier, these notification codes depend on the framework you use, but there are some types that you need to be familiar with, see below:

Notice after return; notice after notification; surrounding circular

Prior notice

Use notifications before some special points in your code-normal is to call a method.

So far, in order to simplify the concept and to make you understand your code faster, I often write the notice to the method. But in the real world, notice is often not written in the method. There should be a separate controller, each of which is in the controller, and each method wraps around the functionality of AOP. This global controller runs throughout the system and is not visible to us.

1. 		<?php

2. Class Pathcontroller
3. {
4. function Controlpaths ($className, $funcName) {
5. Authentication::checkauthentication ();
6. $CLASSOBJ = new $className ();
7. $CLASSOBJ-> $funcName ();
8. }
9. }

Suppose there is a class here that is primarily used to show you what actually happened to this class. Assuming that the Controlpaths method is a global pointcut in the application, each method in the access application needs to be accessed through this method. Before executing each method in the above method, we call the Notification checkauthentication (). -This is the prior notice.

Notify after return

This notification executes only once after the specified feature has been executed, and returns that access point. Consider the following code:

1. 		<?php

2. Class Pathcontroller
3. {
4. function Controlpaths ($className, $funcName) {
5. $CLASSOBJ = new $className ();
6. $CLASSOBJ-> $funcName ();
7. Database::closeconnection ();
8. }
9. }

Notice here, when the method is complete, we clean up the database resources. After the notification is returned, we call this notification.

Notification after throw

If the function throws an exception during the execution of the process, the notification is applied after the exception is thrown. This is when the exception is thrown, and the notification becomes an error message.

1.  <?php   

2. class pathcontroller  
3. { 
4. & Nbsp;   function controlpaths ($className,  $funcName)  { 
5.          try { 
6.               $classObj  = new  $className ();  
7.              $classObj-> $funcName ();  
8.           
9.      & nbsp;  catch  (exception  $e)  { 
10.              error::reporterror ();  
11.           
12.     }  
13. } 

Perimeter Notice

The fourth kind of notice is the peripheral notification, he is the prior notification and returns the notification after the merge body.

1. 		<?php

2. Class Pathcontroller
3. {
4. function Controlpaths ($className, $funcName) {
5. Logger::startlog ();
6. $CLASSOBJ = new $className ();
7. $CLASSOBJ-> $funcName ();
8. Logger::endlog ();
9. }
10. }