Aspect-oriented programming. The basics
We will continue the theme begun in the previous fitting and programmer article about AspectJ and the open source extension for this aspectj-scripting library. In this note, we consider what tasks Aspect-Oriented Programming (AOP) solves by the example and syntax of the most famous library among the adepts of this methodology. AspectJ is a child of Xerox PARC, now full age and living at the Eclipse Foundation.
(photo from the article on lurkmore about renovation)
Probably, the article will not be interesting to those who often use AOP in their work and understand what it is. Comments are welcome as constructive comments and cheerful holivar!
')
Disclaimer: I am not a theorist, so the article told is subjective, passed through the lens of experience.
Why all these difficulties, a different approach to system design, when there is an object-oriented programming? New syntax, some aspects, cuts (pointcut) - after all, everything eventually turns into the same instructions executed by jvm.
The question is in ease of development, ease of modification, testing and cost of system support. Aspects are an addition to OOP programs, another paradigm in developing and designing programs that does not contradict the use of an object model in an application. An analogy that immediately comes to mind is the analysis of sound data. In the time domain with the original signal, it is difficult to perform processing and analysis. But when translating into a frequency representation, it is easy to filter out noises of a certain frequency, highlight the notes in a melody, amplify the sound of a voice, etc. Likewise, aspects make it easy to work with many tasks in a different view of the program and highlight the end-to-end functionality in the form of an aspect. When skillfully applied, AOP helps to “unravel” the “tangled” program code.
There is an opportunity to remove instructions for logging operations (logging) and processing system errors from the application's business logic, reduce the number of boilerplate code, check user access rights when accessing certain methods or fields of the class, declaratively manage database transactions, perform instrumental profiling of the data you are interested in the code section, which takes into account not only the fact of the call and the execution time of the operation, but also some context, caching of "heavy" operations of business logic If they have no side effect, search for places in the program in which the construction of objects of a particular type. This is not limited to the list of what can be convenient AOP. For example, in a project at work, I apply aspects to testing a distributed application, collecting metrics in it, simulating database errors and timeouts inside the jdbc oracle driver, and network interactions.
Let's start with the concept of what advice is in AspectJ - this is how the aspect will be applied in the code cut (pointcut): before the cut (BEFORE), after (AFTER), after a successful return (AFTER RETURNING), in case of an error at the cut point (AFTER THROWING ), or complete control over the situation (AROUND) where you yourself need to call the source code in the slice, transfer the parameters and handle execution errors at the point of the slice.
A pointcut or slice is a description of where we will inject an aspect into the source program. The syntax is quite rich and allows you to describe complex rules that determine the point of cut. For example, constructing an object, static initialization blocks, calling a constructor, accessing fields of an object for reading / writing, constructing an object, catch block, annotated methods, invoking a method with parameters of a certain type, method name by mask, etc. + logical operations in pointcut syntax. Of course, there is no magic in programming, which adds restrictions on what is inline in byte code and not available in pointcuts. Also, not all conceivable cut-off points can be specified declaratively, which sometimes requires an analysis of the call context in the aspect implementation code.
The aspect of the join point in the aspect allows you to get the values ​​of the arguments, find out where the aspect was actually called in the slice, get this object, etc. In the case of AROUND advice, you can immediately make an actual call, change its parameters and get a return value or handle an error.
Everything that at first glance seems to be magic, in AspectJ, is either implemented by a plugin during project building (weaving to bytecode), or by a java agent by modifying program code bytes during class loading (load-time weaving). AspectJ is a mature AOP framework with a huge community, a lot of publications about it, good documentation, fairly stable, integrated into various build systems, integrated into Spring, with good support in the IDE.
In aspectj-scripting (AspectJ java agent extensions), it is possible for aspects at runtime to load classes from the maven repository, read the agent configuration not only from the file and the classpath, but also from the http server. This can greatly help in testing, profiling and modifying a distributed java application. The code is available on github , and the agent is in the central repository . In the last publication I used this library to modify the behavior of the maven plugin About other examples of the use of aspect-oriented programming in practice, I will tell in the following articles.
As the cherry on the cake decorates it and makes it more delicious, so also aspect-oriented programming in an object-oriented program simplifies development, modification, and testing. It is important not to get involved in the use of AOP in the project - so as not to get a cherry pan with a spoon of cream on top!
(photo from the article on lurkmore about renovation)
Probably, the article will not be interesting to those who often use AOP in their work and understand what it is. Comments are welcome as constructive comments and cheerful holivar!
')
Disclaimer: I am not a theorist, so the article told is subjective, passed through the lens of experience.
Why all these difficulties, a different approach to system design, when there is an object-oriented programming? New syntax, some aspects, cuts (pointcut) - after all, everything eventually turns into the same instructions executed by jvm.
The question is in ease of development, ease of modification, testing and cost of system support. Aspects are an addition to OOP programs, another paradigm in developing and designing programs that does not contradict the use of an object model in an application. An analogy that immediately comes to mind is the analysis of sound data. In the time domain with the original signal, it is difficult to perform processing and analysis. But when translating into a frequency representation, it is easy to filter out noises of a certain frequency, highlight the notes in a melody, amplify the sound of a voice, etc. Likewise, aspects make it easy to work with many tasks in a different view of the program and highlight the end-to-end functionality in the form of an aspect. When skillfully applied, AOP helps to “unravel” the “tangled” program code.
There is an opportunity to remove instructions for logging operations (logging) and processing system errors from the application's business logic, reduce the number of boilerplate code, check user access rights when accessing certain methods or fields of the class, declaratively manage database transactions, perform instrumental profiling of the data you are interested in the code section, which takes into account not only the fact of the call and the execution time of the operation, but also some context, caching of "heavy" operations of business logic If they have no side effect, search for places in the program in which the construction of objects of a particular type. This is not limited to the list of what can be convenient AOP. For example, in a project at work, I apply aspects to testing a distributed application, collecting metrics in it, simulating database errors and timeouts inside the jdbc oracle driver, and network interactions.
Let's start with the concept of what advice is in AspectJ - this is how the aspect will be applied in the code cut (pointcut): before the cut (BEFORE), after (AFTER), after a successful return (AFTER RETURNING), in case of an error at the cut point (AFTER THROWING ), or complete control over the situation (AROUND) where you yourself need to call the source code in the slice, transfer the parameters and handle execution errors at the point of the slice.
A pointcut or slice is a description of where we will inject an aspect into the source program. The syntax is quite rich and allows you to describe complex rules that determine the point of cut. For example, constructing an object, static initialization blocks, calling a constructor, accessing fields of an object for reading / writing, constructing an object, catch block, annotated methods, invoking a method with parameters of a certain type, method name by mask, etc. + logical operations in pointcut syntax. Of course, there is no magic in programming, which adds restrictions on what is inline in byte code and not available in pointcuts. Also, not all conceivable cut-off points can be specified declaratively, which sometimes requires an analysis of the call context in the aspect implementation code.
The aspect of the join point in the aspect allows you to get the values ​​of the arguments, find out where the aspect was actually called in the slice, get this object, etc. In the case of AROUND advice, you can immediately make an actual call, change its parameters and get a return value or handle an error.
Everything that at first glance seems to be magic, in AspectJ, is either implemented by a plugin during project building (weaving to bytecode), or by a java agent by modifying program code bytes during class loading (load-time weaving). AspectJ is a mature AOP framework with a huge community, a lot of publications about it, good documentation, fairly stable, integrated into various build systems, integrated into Spring, with good support in the IDE.
In aspectj-scripting (AspectJ java agent extensions), it is possible for aspects at runtime to load classes from the maven repository, read the agent configuration not only from the file and the classpath, but also from the http server. This can greatly help in testing, profiling and modifying a distributed java application. The code is available on github , and the agent is in the central repository . In the last publication I used this library to modify the behavior of the maven plugin About other examples of the use of aspect-oriented programming in practice, I will tell in the following articles.
As the cherry on the cake decorates it and makes it more delicious, so also aspect-oriented programming in an object-oriented program simplifies development, modification, and testing. It is important not to get involved in the use of AOP in the project - so as not to get a cherry pan with a spoon of cream on top!
Source: https://habr.com/ru/post/254791/
All Articles