1:回调还是返回(return)
在写代码的时候，我们经常碰到这样的场景：调用一个函数或者方法时需要返回多个值给上级调用者，如示例：
void methodA(){
Wrap w = methodB();
w.one; //use
w.two;
}
Wrap methodB(){
do something;
return Wrap;
}
class Wrap{
Type one;
Type two;
}
上面是我刚开始写代码时候常用的方式，在多个类型的基础上再封装一个类，返回这个类类型给上层程序处理。在类似情景不多的情况下，采用这种处理方式 是可以接受的。慢慢的，当一个Project的代码越来越多，类似的情况出现频繁的时候，我就开始感到这种处理方式恶心的地方了。
1：为了返回几个不同类型的值，多出来了一个奇怪的类(还得为它想个名字，赋值(set),取值(get),多了n行代码)....
2：返回结果为null ? 为什么会出现null, 出现后怎么处理? 通过向上层抛出异常来处理?每一次遇到这种情况还得回去看原先写的代码，各种陷阱啊~~
更优雅的方式:
interface Callback{
void onCall(Integer one,String two);
void onFail(errorMsg);
}
void methodA(){
methodB(new Callback(){
void onCall(Integer one,String two){
//取得返回值
}
void onFail(errorMsg){
//失败
}
});
}
void methodB(Callback call){
if(success){ //正常
call.onCall(one,two);//one和two为变量
}else{ //有状况
call.onFail(‘get fail‘);
}
}
现在处理返回结果就好多了，代码的可读性也得到了增强，当然，如果你要求返回的结果非常多，还是要封装成一个类比较好点~
2：事件通知
我们先来看一段常用的JS代码
$(‘#id‘).click(function(){
alert(‘click‘);
});
这段代码的工作流程大概就是浏览器捕获到输入设备(鼠标)的点击状态，然后执行click里面的匿名函数，完成整个回调的过程。
类似的情形我们还可以看到很多，尤其在UI的编程中，很多库几乎就是基于事件模型来编写的。下面我们来模拟下载文件进度的事件监听。
interface OnLoadListener{
/**
*@param progress 进度(百分比)
*/
void onLoad(double progress);
}
void download(url,OnLoadListener listener){
InputStream is = getStreamOfUrl(url); //
double totalLen = is.ContentLength; //文件长度
int readLen = 0, hReadLen;
while((readLen=is.read())!=-1){ //从网络上读取.
hReadLen += readLen;
listener.onLoad(hReadLen/totalLen); //把结果即时返回.
}
}
//当我们在UI层调用时：
void show(){
download("http://www.darcye.com/file",new OnLoadListener(){
void onLoad(double progress){
//显示进度
}
});
}
当然，这里只是简单的示例，目的在于说明回调在事件编程模型中的作用。实际上，还有异步，事件队列等许多问题需要进行考虑。
3：分离变化和不变的部分
我们知道，算法的步骤是一样的，只是数据源的类型不一致而已。因此我们可以想办法把不变的算法给分离出来。
相信了解Java的朋友都知道，在API中对对象的排序就是通过回调来解决这个问题的。也就是一种著名的设计模式-模板方法。让我们来看看它的实现过程吧。
我们从这个方法出发:
void java.util.Arrays.sort(T[] a, Comparator c)
深入源码很容易知道，排序的算法就是在这里实现的了，可以看到实现的是合并排序(merge sort)。排序根据(变化的部分)的关键就是这个接口Comparator，再深入代码就可以看到其会回调响应对象实现的接口方法compareTo()。
原文地址： 浅谈“回调”在程序设计中的好处
浅谈“回调”在程序设计中的好处