Java回调--实则是功能共享

A执行操作(doAsOperate)，
调用B的某个操作（doBsOperate），
B在执行操作（doBsOperate）之后的某个条件下，
可以回头调用A的某个操作（doAsCallBack）

这整一个过程叫做回调

那么简单的想来肯定是A中有B，B中有A，比如

public class A{
    private B b = new B(this);
    //A的初始操作
    public void doAsOperate(){
        //doSomeThing
        b.doBsOperate();
    }
    //A的回调操作
    public void doAsCallBack(){

    }
}
public class B{
    private A mA;
    public B(A a){
        mA = a;
    }
    //B的操作
    public void doBsOperate(){
        //doSomeThing
        mA.doAsCallBack();
    }
}

很好，这个时候A执行doAsOperate，调用B的doBsOperate，而B重新调用A的doAsCallBack
很完美的解决了这个回调的实现

但是下面这种才是流行的回调实现，你可以在日常使用中思考下为啥：

public interface CallBack{
    void doCallBack();
}

public class A{
    public A(){
        //在某个地方初始化，这里放在构造函数中
        B b = new B();
        b.setCallBack(new CallBack(){
            public void doCallBack(){
                doAsCallBack();
            }
        });
        //在某个地方调用，这里放在构造函数中
        doAsOperate();
    }
    //A的初始操作
    public void doAsOperate(){
        //doSomeThing
        b.doBsOperate();
    }
    //A的回调操作
    public void doAsCallBack(){

    }

}

public class B{
    CallBack mCallBack;
    public void setCallBack(CallBack callBack){
        mCallBack = callBack;
    }
    //B的操作
    public void doBsOperate(){
        //doSomeThing
        mCallBack.doCallBack();
    }

}

其他没啥区别，主要是增加了接口，让B回头调用A的doAsCallBack多套了一个CallBack的doCallBack方法
从实例化上来讲，就是B不再需要有A的实例，而只需要有CallBack的实例

而正是这个CallBack导致我最开始学习的时候卡在回调的理解上，卡了一天半的时间。

为什么呢，因为这里的CallBack其实上是一个C的角色，和开头的回调说只有A和B的模型不符合
如果没有前面的简单例子做铺垫，直接进行理解，我认为java流行的回调模型应该是这样子的：

A做了一个机关，可以让C来触发，而A现在因为一些原因（也许是赖床）触发不了机关，他把C交给B，说只要怎么怎么样，你就可以用C触发机关，这样我这边机关就会产生一系列的后续联动（也许就是叫A起床）。

这样其实已经偏离了最初的回调概念，但是效果是一样的，所以还是叫回调咯。而这C的关键实现方式，便是功能共享