Groovy探索之MOP 十三 Interceptor 三(1)

本篇的“Interceptor”,主要是来说说拦截器的阻止拦截的问题,这个问题是我们自定义拦截器时经常要遇到的挑战之一。

与阻止拦截很近的一个意思是不拦截,即我们可以拦截某个方法,但我们不对拦截做任何实质性的动作,即我们简单的将拦截的动作放行。这是一种被动的不拦截行为。而我们的阻止拦截却更为主动一些,即不让拦截器拦截到某个方法。

下面,我们将分别就放行拦截和阻止拦截来举例说明。

首先,我们还是设计一个需要被拦截的类来:

class Foo {
def foo()
{
println 'foo'
}
def bar()
{
println 'bar'
}
}

假设我们不想拦截“bar”方法,只想拦截“foo”方法,则我们可以这样设计拦截器:

class NoBarInterceptor implements Interceptor{
Object beforeInvoke(Object object, String methodName, Object[] arguments){
if(methodName == 'foo')
{
println 'interceptor the function: foo'
}
}
boolean doInvoke(){ true }
Object afterInvoke(Object object, String methodName, Object[] arguments,
Object result){
result
}
}

在代码中,我们只拦截了方法名为“foo”的方法,对其他方法则未做处理,即放行了。我们来写一点测试代码:

def proxy= ProxyMetaClass.getInstance( Foo )
proxy.interceptor= new NoBarInterceptor()
proxy.use{
def f= new Foo()
f.foo()
f.bar()
}

运行结果为:

interceptor the function: foo
foo
bar

当然了,如果我们想更加主动的确定对哪些方法放行,则可以这样设计我们的拦截器:

class NoMethodInterceptor implements Interceptor{
def methods
Object beforeInvoke(Object object, String methodName, Object[] arguments){
if(!(methodName in this.methods))
{
println "before invoking $methodName"
}
null
}
boolean doInvoke(){ true }
Object afterInvoke(Object object, String methodName, Object[] arguments,
Object result){
result
}
}

时间: 2024-11-18 07:18:21

Groovy探索之MOP 十三 Interceptor 三(1)的相关文章

Groovy探索之MOP 十三 Interceptor 三(2)

其实,阻止拦截的使用像在<Groovy探索之MOP 十三 Interceptor 三(1)>中的最后一个例子那像的使用并不多,更多的是在使用拦截器的客户那里决定是否使用拦截器.还是上一篇的那个例子: class Hello { def hello(name) { "hello,$name" } } 我们现在明确的把类中所有的方法进行拦截,拦截器如下: class AllInterceptor implements Interceptor{ Object beforeInvo

Groovy探索之MOP 十 Interceptor 二

在本系列的<Groovy探索之MOP 九 Interceptor 一>中,我们已经详细的介绍了一个简单的拦截器类的方方面面,使得我们初步有了拦截器的基础.本篇需要在前面的拦截器类的基础上,进一步用拦截器类来实现我们的AOP编程. 首先,我们在本系列的第一篇中,所拦截的方法都是固定的方法.现在,我们需要把它扩展成由拦截器类的使用者来指定被拦截的方法. 先还是给出需要被拦截的类来: class Foo { def test1() { println 'test1' } def test2() {

Groovy探索之MOP 九 Interceptor 一

近几年以来,AOP(面向方面的编程)得到了广泛的应用,我们把它应用到例如打印日志.权限控制等各个方面.而在实现AOP的时候,我们一般都借助于工具,如Spring AOP等等. 当然,我们借助于工具一般都用在实现系统级的AOP上,这种实现一般都要借助于配置文档来实现. 当我们需要实现较小范围的AOP的时候,比如对有限几个类的某些方法进行AOP,这时候,我们一般不希望使用工具.原因可能是第一工具不够灵活第二需要做繁琐的配置工作.这时候,我们需要自己来实现AOP的方方面面. Java语言一般来说,有两

Groovy探索之MOP 十五 方法名的动态性

到目前为止,我们的<Groovy探索之MOP>系列已经谈到了使用ExpandoMetaClass的方方面面,但值得注意的是,我们通过ExpandoMetaClass给一个类在运行期内添加一个方法,不管是普通方法还是静态方法,我们都是添加一个确定方法名的方法.即我们添加一个方法名为A的方法,然后才能使用这个方法A. 然而,方法名的动态性,其实是我们早已接触过的事情,比如在<Groovy探索之invokeMethod方法>里,我们就可以创建形如"sortByXxxxx()&q

Groovy探索之MOP 十二 方法的调用顺序

我们知道,除了使用hook来拦截方法以外,我们还可以通过各种方式来实现方法.如,我们可以在类里直接实现方法:我们可以通过ExpandoMetaClass在运行期内添加方法:我们还可以通过ExpandoMetaClass在运行期内单独给一个对象添加方法. 所有的这些直接添加方法的途径,如果存在hook的话,都是要被hook拦截的.所以,我们可以说,系统是优先调用hook的. 而hook的调用顺序,我们在上一篇<Groovy探索之MOP 十一 运行期内覆盖invokeMethod>已经谈到过了.

Groovy探索之MOP 十一 运行期内覆盖invokeMethod

我们很早就会使用Groovy语言的hook,即"invokeMethod"方法和其他的几个方法.我们会在一个类中实现"invokeMethod"方法,用来分派所有的或部分的在运行期内调用的该类实例的方法.这些我们在<Groovy探索之MOP 一 invokeMethod和methodMissing方法>已经详细的谈到过. 现在,我们已经深入的接触到了Groovy语言的MetaClass,更是也到处使用到了ExpandoMetaClass.我们都已经知道,

Groovy探索之MOP 三 Class、MetaClass和ExpandoMetaClass

Class当然是Groovy语言从Java语言继承来的,这就是说Groovy语言也继承了Java语言的反射机制.这意味着我们能够像在Java语言里使用反射那样,在Groovy语言里写出诸如下面的代码: import java.lang.reflect.Method class Testor { def testDelegate() { 'ok' } static void main(args) { def t = new Testor() Class cls = t.class Method m

Groovy探索之MOP 十四 对Java类使用Groovy语言的MOP

既然Groovy语言是Java语言的扩展,那么我们在使用Groovy语言的时候,就很难与Java语言真正脱得了干系,那怕我们是在做一个纯Groovy语言的项目,如Grails项目.我们可能在Groovy代码中会用到遗留的Java类和包:也可能是为了性能的原因,我们不得不在Groovy语言中使用到Java类:等等. 如果我们要对于Java类使用Groovy语言的MOP,比如我们想给一个Java类的对象在运行期内添加一个方法.那么我们该怎么办呢? 比如,我们有如下的一个Java类: //(Java代

Groovy探索之MOP 七 运行期内的方法和属性分析

在Groovy语言里,运行期内的方法和属性分析有三种方式,它们分别是: 第一, 继承自Java语言的反射方式. 第二, 使用"respondsTo"和"hasProperty"方法. 第三, 使用"hasMetaMethod"和"hasMetaProperty"方法. 以上三种方法都能在运行期内分析某个方法或属性是否存在,相信我们看到这里,一定会想,它们之间是否有什么区别呢? 漫谈这三种运行期内的方法和属性分析方式以及它们之间