回调函数大家一定不陌生，本质上就是个函数指针。运行机制今天不必赘述，今天只说说他的作用（必要性）。
多年前就思考过这个问题，但是每个阶段可能会有不同的体会吧。今天在CSDN博客上看关于回调的应用场景的一句话：“你想让别人的代码调用你的函数，但是你又不能改别人的代码”。
所谓不能改别人的代码，其实是出于封装解耦的目的，对方未必真的提供源码给你，比如编译好的模块，只给你开放个API，这时候你不能修改也不能要求对方俢改代码。所以只有一条路，把你的函数通过事先定义好的参数传给对方。如果还不直观，我们来一个例子：
假设模块A（作为调用方）和模块B（被调用方）：
A需要完成的工作是：（1）定义回调函数： void callbackfun() {...} (2)注册回调函数，即在调用B的函数func时将回调函数传入： func(callbackfun).
B需要完成的工作是：定义函数func,并通过头文件提供API给A，在func中适合的时机回调callbaclfun：
void func(void (*p))
{ ........
(*p)();
........
}
从上面的例子可以看出，如果A直接定义一个函数funa实现回调函数的功能，并提供给B调用，也可以实现同样的功能。这样似乎就不必使用什么回调机制了。确实，实现上可以这样，但会有两个问题：（1）A调用B的函数，B再调用A的函数，两个模块循环调用，耦合太强不说，声明函数的头文件之间的相互包含，还会产生编译问题。(2)这样实现模块B硬调用A的函数，实现上势必要求B的代码实现需要根据A的要求来进行修改。
所以现在能体会回调的优点了吧。
下面引用CSDN网友[TNT_snowball]的一段解释，觉得真的贴切明了。
我们为什么要用回调函数呢？
记得在一次C++开发面试的时候被被一位主面官问到过这个问题，现在再回答一遍。
我们对回调函数的使用无非是对函数指针的应用，函数指针的概念本身很简单，但是把函数指针应用于回调函数就体现了一种解决问题的策略，一种设计系统的思想。
在解释这种思想前我想先说明一下，回调函数固然能解决一部分系统架构问题但是绝不能再系统内到处都是，如果你发现你的系统内到处都是回调函数，那么你一定要重构你的系统。回调函数本身是一种破坏系统结构的设计思路，回调函数会绝对的变化系统的运行轨迹，执行顺序，调用顺序。回调函数的出现会让读到你的代码的人非常的懵头转向。
那么什么是回调函数呢，那是不得以而为之的设计策略，想象一种系统实现：在一个下载系统中有一个文件下载模块和一个下载文件当前进度显示模块，系统要求实时的显示文件的下载进度，想想很简单在面向对象的世界里无非是实现两个类而已。但是问题恰恰出在这里，显示模块如何驱动下载进度条？显示模块不知道也不应该知道下载模块所知道的文件下载进度（面向对象设计的封装性，模块间要解耦，模块内要内聚），文件下载进度是只有下载模块才知道的事情，解决方案很简单给下载模块传递一个函数指针作为回调函数驱动显示模块的显示进度。
在面向对象的世界中这样的例子还真不少，造成这样的问题的根源，相信大家已经从上面的叙述中体会到了，就是面向对象的程序设计思想，就是设计模式中要求的模块独立性，高内聚低耦合等特性。
封装变化的编程策略给编程人员第一位的指导思想就是面向接口编程，即设计模式中提到的面向虚拟编程而不是面向实现。这样的编程思想极大地革新了编程世界，可以说没有这一原则就没有面向对象的程序设计，这一原则给程序设计一种指导思想即如何更高的将现实模型映射成程序模型。这样的设计思想在极大地催生高度独立性模块的同时削弱了模块间的协作性，也就是耦合性，它使得模块间更多的从事着单向的调用工作，一个模块需要某种服务就去找另一个模块，这使得程序呈现出层次性，高层通过接口调用底层，底层提供服务。但是现实世界中严格遵循现层次特性的系统是很少见的，绝对的MVC是不存在的，因为更多的模块要求通并协作，可见没有耦合就没有协作没有好的调用关系，耦合真的不是错。
既然我们需要模块间的协作，同时我们又厌恶的摒弃模块间你中有我我中有你的暧昧关系那如何生成系统呢，答案是函数指针（不一定一定是函数指针）也就是使用回调的方式。如果一个对象关心另一个对象的状态变化那么给状态的变化注册回调函数让它通知你这类状态的改变，这样在封装了模块变化的同时实现了模块间的协作关系另辟独径的给对象解耦。