对callback,暂时的理解是:A对象调用B接口的b方法,b方法又反过来调用A对象中的c方法。
A调用B接口时把自身给B接口,至于怎么处理,由B的实现类去做,不关A的事。
写了个例子,BadBoy,这类坏孩子喜欢打人,有个方法叫hit,hit只能对实现了Hitable的对象执行。
这时候,BadBoy已经做完了自己的事,也就是已经打完人了,然后挨打的人肯定知道是谁打了自己,
至于挨打的人是什么反应,BadBoy是无法控制的。挨打的人有可能哭有可能跑有可能报警。
第二种理解:
【1】必须有一个接口,声明实现子类必须实现的方法,比如:
public interface Icalc{
public Object doCalc(int a,int b);
}
【2】中间使用类在自己方法中只针对以上接口进行编程,在自己的方法中以 接口为参数,在方法体中调用接口的方法来完成自己额业务逻辑,具体的逻辑实现不用考虑。
具体实现被推给调用这个使用类的用户完成!
【3】最外层是真正业务逻辑代码的提供者,它去调用【2】步骤中定义的方法时,因为该方法有一个接口参数的变量,
因此它必须在这时实现这个接口,供【2】步骤中相应方法来调用。
本来是调用【2】步骤中的方法,到真正调用时,反过来【2】步骤的方法还要调用【3】步骤中对接口的实现,来完成业务逻辑,
这正应了这个概念的名字 "回调(callback)" !
第三种理解:
总听见Callback如何如何,姑且不评判它的好坏,但是的确提供了一种code的新方式。
Callback我理解是调用方 调用 被调用方函数执行过程中,
被调用方 选择执行 调用方(至少是调用方初始化出来的)的某些函数来通知 调用方或者按照调用方的意愿做某些改变。
Spring中的JdbcTemplate的query方法和execute方法就使用了大量的Callback。
初始场景:A——调用者;B——被调用者。
最简单的方式是 A的方法调用B的过程中,A将自身this作为一个参数传递给到b的执行函数中。
这样,在执行b的方法时,就能够反过来操纵a的方法了。但是这种方式A和B循环依赖。不是一种很好的选择。
一种更为优雅的方式是:申明一个ICallBack接口,作为执行B方法的参数。
B在执行自己代码的过程中,执行callback对象对应的方法。
那么,在A开始调用时,实现ICallBack接口(可以大量使用A自身的资源:a知道该怎么办),并且在调用B方法时将callback对象传入。
这样,A依赖于Callback,B也依赖于CallBack。因此有效的解耦。
应用场景:A有多个方法要调用B的某个方法,B的这个方法很多逻辑相同,但是,小部分逻辑根据A的调用方法不同而不同。
因此,使用Callback方法:1)创建ICallback接口;
2)在A的调用地方实现callback类;
3)在这个类中写不同的业务逻辑;
4)B的方法写固定的业务逻辑并且接受ICallBack对象执行。
可能出现的问题:如果A的若干个执行方法中,要求响应对象不一致,尝试泛型是否可以解决!
实例理解:
测试类:
JAVA实现回调【摘抄,很经典】
熟悉MS-Windows和X Windows事件驱动设计模式的开发人员,通常是把一个方法的指针传递给事件源,当某一事件发生时来调用这个方法(也称为“回调”)。
Java的面向对象的模型目前不支持方法指针,似乎不能使用这种方便的机制。
Java支持interface,通过interface可以实现相同的回调。其诀窍就在于定义一个简单的interface,申明一个被希望回调的方法。
例如,假定当某一事件发生时会得到通知,我们可以定义一个interface:
这样我们就有了任何一个实现了这个接口类对象的手柄grip。
当一事件发生时,需要通知实现InterestingEvent 接口的对象,并调用interestingEvent() 方法。
在这个例子中,用somethingHappened 来标志事件是否发生。
希望接收事件通知的类必须要实现InterestingEvent 接口,而且要把自己的引用传递给事件的通知者。
以上是通过一个非常简单的例子来说明Java中的回调的实现。
以下为经典实例演示:
当然,也可以在事件管理或事件通知者类中,通过注册的方式来注册多个对此事件感兴趣的对象。
1. 定义一个接口InterestingEvent ,回调方法nterestingEvent(String event) 简单接收一个String 参数。
2. 实现InterestingEvent接口,事件处理类
3. 事件管理者,或事件通知者
4. 测试