Exploration of groovy mop 10 interceptor 2
In this series of "explore groovy mop nine interceptor 1", we have introduced in detail all aspects of a simple interceptor class, so that we have a preliminary foundation of the interceptor. In this article, we need to use the interceptor class to implement our AOP programming on the basis of the previous interceptor class.
First, in the first part of this series, the methods intercepted are fixed methods. Now, we need to extend it to the user of the interceptor class to specify the method to be intercepted.
First, we will give the classes to be intercepted:
ClassFoo {
DefTest1 ()
{
Println'Test1'
}
DefTest2 ()
{
Println'Test2'
}
DefTest3 ()
{
Println'Test3'
}
}
Then we will provide our interceptor class:
ClassMethodsinterceptorImplementsInterceptor {
DefMethods
Object beforeinvoke (Object object, string methodname, object [] arguments ){
If(MethodnameIn This. Methods)
{
Println"Before invoking $ methodname"
}
Null
}
BooleanDoinvoke (){True}
Object afterinvoke (Object object, string methodname, object [] arguments,
Object result ){
If(MethodnameIn This. Methods)
{
Println"After invoking $ methodname"
}
Result
}
}
With the foundation of the previous article, this interceptor class is better understood. The difference is that in the interceptor class of the previous article, the method to intercept is fixed, and the method to intercept the interceptor is determined by the attribute "methods.
Let's see how we use this interceptor class:
DefProxy = proxymetaclass. getinstance (FOO)
Proxy. interceptor =NewMethodsinterceptor (Methods: ['test1', 'test2'])
Proxy. Use {
DefF =NewFoo ()
F. test1 ()
F. Test2 ()
F. test3 ()
}
The running result is:
Before invoking test1
Test1
After invoking test1
Before invoking Test2
Test2
After invoking Test2
Test3
With this customer's given parameters to intercept, we have taken the first step towards AOP programming.
Next, we need different classes of the Interceptor to intercept the function. In this way, we can say that we have initially completed a simple AOP programming.
Next, let's make a simple help class so that our interceptor can intercept different classes:
ClassInterceptorhelper {
Def StaticIntercept (class clzz, methodnames, closure)
{
DefProxy = proxymetaclass. getinstance (clzz)
Proxy. interceptor =NewMethodsinterceptor (Methods: methodnames)
Proxy. Use {
Closure.Call()
}
}
}
This tool class requires three parameters: "clzz", the class of the object to be intercepted, "methodnames", and "closure" to call the methods to be intercepted.
The following is a test case:
Interceptorhelper. Intercept (Foo, ['test1', 'test2']) {
DefF =NewFoo ()
F. test1 ()
F. Test2 ()
F. test3 ()
}
The running result is:
Before invoking test1
Test1
After invoking test1
Before invoking Test2
Test2
After invoking Test2
Test3
To test whether the above tool class can intercept other classes, we made a special test, assuming there is a class as follows:
ClassToo {
DefTest1 ()
{
Println'Too1'
}
DefTest2 ()
{
Println'Too2'
}
}
Let's also test whether our tool class can intercept this class:
Interceptorhelper. Intercept (too, ['test1', 'test2']) {
DefT =NewToo ()
T. test1 ()
T. Test2 ()
}
The running result is:
Before invoking test1
Too1
After invoking test1
Before invoking Test2
Too2
After invoking Test2
We can see that the given methods of different classes can be intercepted. In this way, we have taken a key step towards AOP programming. In the future, we may put forward various requirements for our interceptor classes and AOP tools in the actual coding process. But they can all be extended from the above example.
We can try to implement the following:
How can we intercept all methods except the constructor and policyobject methods for the objects we specify on the client.
How can we implement some non-blocking methods for the objects we specify on the client.
From these various requirements, we can see that implementing our own AOP programming can indeed achieve convenient and flexible purposes according to the actual requirements in the project.