前言：本文原作者是王钦誉，原文链接：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方法， 就可以被调用， 小张好奇心大起，决定去出去闯一闯。
（完）
码农翻身相关历史文章推荐：
操作系统
Java EE
计算机网络
数据库
你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan QQ: 3340792577
公众号：码农翻身
“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。
1万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
