Question

前言：本文原作者是 王钦誉， 原文链接： https://xiaoqinyu0000.github.io/Java/JavaCallback/

我对文章做了修改， 文章主要介绍 Java 的回调机制及其实现。

故事背景

在日常编程中，我们经常需要对内存的数据进行持久化的工作，把他们保存在硬盘文件或者数据库中。

为了避免重复， 我们通常会把这部分工作封装在一个工具类中， 让各个客户端来调用。

下文的 FileIO 就是一个简单的工具类（为了简单起见，并没有使用单例或静态方法来实现）

小张的烦恼

Java 帝国的 FileIO 是一个忙碌的家伙，附近 7、8 个村落的人都来找他， 请他把数据存储到硬盘里。

FileIO 提供了一个简单的接口， 大家只要告诉他文件名和要保存的字符串内容， 剩下的事就只是等待了，FileIO 会完成工作，告诉大家是成功还是失败。

比如张家村的小张来请 FileIO 保存文件的时候是这样的：

通常情况下， 小张都会很快拿到返回结果， 高高兴兴的回家。

但这一次不知道怎么回事， 这个 FileIO 一直不返回结果， 把小张阻塞了长达 1 秒钟！

小张说： “哥们， 怎么回事？ 我这儿都等了 1000 毫秒了， 还没完？

FileIO 回答 ： ”这不能怪我啊， 你这次的数据量实在是太大了，是谁上传的大文件故意捣乱吧， 对了， 你杀毒没有？“

"安全问题不用你考虑 " 小张也有点底气不足 ：”我觉得数据量还行， 也有可能是硬盘这会儿太忙了”

总之，小张一直阻塞在那里，无法回家。

回调

阻塞的事情发生的多了，极大的影响了小张的工作， 最近这一周的工分可是落后了不少啊， 再这么下去，月底分粮的时候就要饿肚子了， 饿肚子还是小事， 自己喜欢的张二妮看到没粮食，估计就不理我了。。。

他拎了两瓶好酒去找 FileIO 商量： “兄弟， 我听说有一种异步保存的办法， 你那边能不能用下？ 保存数据的时候起一个线程， 把主线程让回给我，保存好了再通知我，我也不用老是等你，是吧？”

FIleIO 想了想说：“这样确实可以解决问题，但每天找我保存数据的人也很多，而且我也不知道在完成数据的写入之后怎么通知你呢？”

小张把两瓶好酒往前一推， “我们关系这么好，你再开个专属我的方法呗，我在调用你的 saveStrToFile 方法的时候顺便把我的实例给你，你搞完之后通过我的实例调用我的方法通知我就行啦。就调我的 onResult() 这个方法吧。这事要保密， 天知地知你知我知就行了”。

于是，FileIO 为小张开了一个 VIP 通道：

这种方式很巧妙，小张调用 FileIO 的 saveStrToFile(String,String,XiaoZhang) 的时候，把自己的实例通过第三个参数给了 FileIO，FileIO 开启子线程保存完数据之后，通过 XiaoZhang 给的实例回调 onResult(boolean) 方法。

听起来很绕口，但总结起来就 我调你的方法，你再回调我的方法 。

后来，JAVA 帝国给这种机制取了个名字叫 回调机制 ，在帝国中广为人知。

酒后泄密

由于有了 FileIO 的 VIP 通道，小张处理业务的能力大幅度提升， 工分不但在张家村独占鳌头， 就是算上李家村， 刘家村 等，那也是数一数二的。

小张一时风光不已，越来越多的人来向他请教秘诀，但小张却笑而不语（这可是成功秘诀，能告诉你们嘛...）。

有一次， 李家村的小李看到了 FileIO 有了一个新接口（毕竟都是公开的嘛）， 但是不知道怎么回事， 自己也调用不了， 类型不对啊。

小李别有用心的请小张和 FileIO 喝酒， 酒过三巡， 俩人终于吐露了这个秘密。

这一下子炸开了锅， 虽然 Java 帝国规定， 接口的设计一定要规范， 不能乱来， 但是大家蜂拥而至， 纷纷要求 FileIO 给自己也开 VIP 通道。

FileIO 实在是没有办法， 无奈之下为小李， 小王等等都开启了 VIP 通道：

村长支招

随着 FileIO 开启的 VIP 通道越来越多，FIleIO 发现自己的体积越来越膨胀，自己有大量的代码是在处理这些 VIP 通道，而且处理方式都差不多，VIP 通道多了也就失去其意义了。

有一次， 张家村德高望重的村长路过 FileIO 这里，FileIO 知道村长软件设计能力了得， 赶紧拉住就行讨教。

村长果然见(lao) 多(jian) 识(ju) 广(hua)，“小伙子，既然我们村的成员老是需要你的帮助，你就别为每个人开启一个 VIP 通道，你直接弄一个我们张家村的 VIP 通道，这个通道不是接受张大胖， 张二胖这样的类， 而是接受一个 ZhangClient 的抽象类。这个抽象类中只有一个方法：onResult

每次，有人去找你帮忙的时候，你也不用管具体是谁，只要他实现了 ZhangClient，你就知道它有一个 onResult（false）的方法，你处理完了之后直接回调它的 onResult(boolean) 方法就行了，是不是很简单啊，哈哈哈哈哈～～～”

FileIO 听完老村长的话恍然大悟， 这一层解决不了的事，那我们再加一层，在上一层解决呗 ：

如上所示，FileIO 表面上回调了 ZhangClient 的 onResult(false) 方法，但实际上回调的是 XiaoZhang 的 onResult(false) 方法，因为传进来的实例实际上是继承了 ZhangClient 的小张（作者：感觉像披着羊皮的狼）。

后来，帝国将这种利用抽象类去实现回调的方式称之为 抽象类回调 。

Java 巡视组

FileIO 把其他通道都删除了， 只留了一个 ZhangClient 通道， 现在他明白老村长的老奸巨猾了。

因为李家村、赵家村、王家村的人都抱怨说， 我们找你保存个数据， 还得继承一个姓 Zhang 的类， 实在是太扯了！

FileIO 想了想， 得了， 为了避免引起众怒， 还是改个名称吧，就叫 FileIOClient 。

即使是这样， 很多人还在抱怨： 我已经继承了一个类了， 怎么可能再继承你这个 FileIOClient ？ 不继承就没法保存数据， 还有没有王法了！ 还有，你这老是改来该去， 把我们都该累死了。

事情闹大了， 上面派了个巡视组下来解决。

FileIO 战战兢兢的给巡视组诉苦： ”我也实在是没办法啊， 你看 Java 也不允许多继承， 我昨晚想起一个办法， JAVA 类都隐性继承 Object，能不能在 Object 里面增加一个回调的方法？“

巡视组生气的说：”别做梦了！ java.lang.Object 是我们的根， 那是你加方法的地方吗？！ 你整天只知道保存数据， 难道都忘了 Java 帝国的接口（interface）了吗？“

FileIO 被点醒了， 既然继承的方式搞不定，那就接口好了， 接口可以随意实现， 想实现几个实现几个。

在巡查组的监视下， FileIO 很快修改了代码：

不幸的是， 大家的代码也都得改一遍， 万幸的是， 只需要把 extends FileIOClient 改为 implements IFileIOCallBack 即可。

后来，帝国将这种利用接口去实现回调机制的方式称之为 接口回调。

尾声

张家村的小张有点落寞， 他原来独有的回调方法现在已经被接口回调所替代，他独有的优势已经荡然无存，风光不再。

更让他烦心的事， 随着 FileIO 接口的变化， 他的代码也不断的改来改去， 光是修改就耽误了不少事儿，少挣了好多工分。

不就是一个回调吗， 还继承这个， 实现那个的， 这 Java 搞的也太复杂了。

有小道消息说，Java 帝国之外的动态语言王国有个叫 Duck Typing 的东西， 实现回调的时候根本不用继承什么东西， 也不用实现什么接口， 只要自己有一个 onResult 方法， 就可以被调用， 小张好奇心大起，决定去出去闯一闯。