第一遍看完之后，对于整体的框架有了一个理解。这段时间对回调，及一些设计模式有了更加深入的了解之后，重温第二遍。个人觉得可以这么理解，若有问题，希望指正。

正向的逻辑看前面同学整理的流程图即可。

我来谈谈我对与回调的看法。上层调用下层，是我们的惯用的思想。上层不管下层做了什么，我只需要让下层去完成就好了。如课程中的，Sender需要发送了，调用IoProvider。上级只需要知道，我现在想要发送，至于IoProvider怎么准备这个发送的流程就不需要知道了。若是我们调用下层的时候，还需要知道下层处理完了没有呢？又如上面的例子，IoProvider已经准备好发送了，肯定要通知上层Sender来进行真正的发送方法。

怎么让上层知道呢？最原始的办法，当然是老板亲自监督，也就是，在调用IoProvider的时候，我们把sender也传入，当下层准备完成后，就可以直接调用老板的发送方法。（这其实已经有一点回调的思想了）但是这样会有两个问题：第一个，如果有Sender1和Sender2 两类的老板，都想让你做这件事，那么你该怎么办？难道不断的让方法重载嘛？这个很简单，继承一个公共类，或者继承一个公共接口即可，利用向上转型的机制，可以简化我们的代码。然后就是选择类还是接口的问题了，从结果来看，我们选择了接口。至于为什么选择接口，这就要提到上面的第二个问题了，因为如果将类传递下去，那么上层就对下层透明了，下层可以轻松的调用上层的方法，这让上下层分级制度出现漏洞。其实下级与上级的关联就只有一种行为-通知，上层只要有被通知的这种功能即可，那我们将功能抽象成接口，就是上级实现了这种接口就可以了。这样下级就最多就只能访问接口中的方法了，上级维护了它的神秘感。

回调的具体做法就是，上级实现了回调接口，并在下级中注册，当下级完成某件事情之后，就可以调用这个注册接口的方法来让上级知道。

以上就是对于回调的一些基础理解了，回调的好处就是可以解耦。

所以回调，我们抓住四点：1、上级是谁；2，下级是谁；3、上级想知道什么（知道后才可以做后续的操作）；4、下级做什么之后，才会通知上级。

下面让我们看看第七八章中的一些例子：

第一个就是上面举的例子了， 上级SocketChannelAdapter实现了HandlerproviderCallback的接口，并且将其注册到了IoSelectorProvider之中，当可以处理数据时，下层就回调了接口中的方法。上级就让其来真正的实现接受。如用IoArgs来读取数据之类的。

第二就是，上层ReceiverDispatcher实现了IoArgsEventListener接口，并在SocketChannelProv中注册了，当下层IoArgs读取到数据之后，就会回调给上层，ReceiverDispatcher就会处理这个IoArgs，打包成Packet。

第三就是，Connector实现了一个回调接口，并在ReceiverDispatcher注册了，当下层Packet打包完成之后，就会回调给上层，让Connector打印数据。（Server还需要广播）。

这三个回调基本就完成了数据接受的一个过程。其余的回调套用这个模板，应该也能慢慢理解了。

这门课程确实让我受益很多，感谢老师。若是有一些错误或者不恰当的地方，希望老师和同学能够指出。共同学习，共同进步。