Frontend interpretation of Aspect-oriented programming (AOP)

Preface

As a classic design paradigm, object-oriented (OOP) is a classic summary for us. Do you still remember the classic summary at the beginning of the line-Everything is an object.
Yes. Based on the characteristics of OOP encapsulation, inheritance, and polymorphism, we will naturally follow the modular and componentized thinking to design and develop applications, to achieve easy maintenance, scalability, and high reuse.
Since OOP has so many advantages, we often mention what the Aspect-oriented programming (AOP) is. Let's take a look at it.

AOP Definition

The first step is to know what AOP is, first from Wikipedia:

Aspect-Oriented Programming (Aspect-Oriented Programming and AOP) is a term in computer science, A programming paradigm.
The concept on the side is derived from the improvement of object-oriented programming, but it is not limited to this. It can also be used to improve traditional functions.

The separation of cross-cutting concerns from the main concerns is the core concept of side-oriented programming. The separation of focus makes the code that solves problems in specific fields independent from the business logic.
The business logic Code does not contain Code calls for specific domain issues. The relationship between business logic and specific domain issues is encapsulated and maintained through the sides.
In this way, changes originally distributed throughout the application can be well managed.

Tip

It is a bit unclear and messy. However, before going into chaos, let's take a look at what we can understand:

• The side (that is, the aspect) is used to describe cross-cutting concerns in objects, classes, or functions..
  This focuses on cross-cutting concerns distributed in objects. You can guess what it is, which should be the common part of different objects.
  
• The concept is derived from the improvement of object-oriented programming. It can also be used to improve traditional functions..
  AOP is clearly not a substitute for Oop, but a supplement to OOP.
  
• Separating the cross-cutting concerns from the main concerns is the core concept of side-oriented programming.
  Specifically for business projects, the main focus is the business logic. Code calls targeting specific fields are part of the attention of AOP

In short, AOP extracts aspect (that is, non-business logic, such as error processing, tracking, and logs) from the service processing process.
It is faced with a step or stage in the processing process to achieve the isolation effect of low coupling between parts in the logical process (the purpose is to reduce coupling ).
Specifically, the implementation is to dynamically Insert the non-primary focus into the primary focus (generally in the business logic)

If you say so much, you may not understand it. Let's look at the Code together.

Tracking scenario

In such a common scenario, you need to click the button to report the information.
Assume that we have such a logger tool for reporting:

Const logger = console. Log // you can use logger after import ('button clicked ')

So let's just pull it up:

Const dosomething = () => {console. log ('dosomething ')} Let clickhandler = () => {logger (before 'dosomething') // n lines of code dosomething () Logger (after 'dosomething ') // n lines of code}

It seems nothing, simple and rude.
If there are 30 buttons and each business logic is different, we need to bury this point (assuming the hitting information is consistent ).
If we have to manually write this method in the 30 functions, it's too boring.
It is mainly due to severe coupling with the Business Code. On that day, some other content is greatly improved, and the handshakes are deleted by mistake.
During subsequent maintenance, it was a nightmare.
Let's take a closer look at this. Isn't that the prerequisite for using AOP? Try AOP.

Focus Division

According to the above mentioned, you can divide the following concerns.

Main focus	Side concerns
Dosomething)	Tracking Information Logger

As mentioned above, AOP focuses on the steps. Specific steps are actually the steps for inserting logger.
The insertion time is nothing more than the phase before or after the business logic is executed.
Implementation is not that difficult

Implementation

Specifically, due to the characteristics of the language itself, JS is born with the ability to dynamically insert logic during runtime.
The point is that adding other functions to the original function does not change the function itself.

After all, functions can accept parameters in all forms. Of course, functions are no exception.
When a function is passed in, we have a lot of room for its operations,
Save the original function and add call or apply to the subsequent parameters to achieve our goal.
In addition, in order to add an attribute to the function, we can operate on the prototype.

Implementation of classic before or after

There are too many similar implementations on the Internet. You can check the Code directly:

// Action is our side concern, that is, loggerfunction. prototype. after = function (Action) {// retain the current function. Here this points to the function that runs clickhandler var func = This; // return is the encapsulated function, other functions can be executed here. // And the method is attached to function. on prototype, // The returned function still has the after attribute. You can call return function () {// to run the original function. asynchronous var result = func is not considered here. apply (this, arguments); // action after execution. apply (this, arguments); // return result; };}; // before implementation is similar, but the execution order is different. prototype. before = function (Action) {var func = This; return function () {action. apply (this, arguments); Return func. apply (this, arguments );};};

The code after the transformation using AOP is as follows:

Const dosomething = () => {console. log ('dosomething ')} Let clickhandler = () => {// n lines of code dosomething () // n lines of code} clickhandler = clickhandler. before () =>{ logger (before 'dosomething ')}). after () => {logger (after 'dosomething ')}) clickhandler () // The execution result is consistent with the expected

Now we have implemented Aspect-oriented programming. In our business logic, we only care about the business itself. The side concerns are dynamically introduced in this way, decoupled from the main logic, making it more pure and easy to maintain.

Conclusion

Here, a simple introduction to AOP is complete. With this mode combined with the features of JS itself, we can try more possibilities.
For example, in react, we often use the Hoc, es7 modifier mode, Hof, and so on. Many times, we have to lament the essence of the ideas of the scalpers, which gives us an epiphany. This article will help you learn from each other and summarize and improve yourself. We hope that you can help your friends who need it. For more articles, go to my blog

References

Allyteam-use AOP to improve JavaScript code
Javascript decorators and AOP Programming

Frontend interpretation of Aspect-oriented programming (AOP)