回调函数引发的自省

每次看到回调函数我都会纠结一下，因为我不会。尽管每次都会重新学习一遍，但是从来没用过，过几天就会忘记。经常看到别人说回调函数好用，今天就再次从网上学习了一遍回调函数。看完之后，觉得回调函数...就这？附段学习网站的代码：

#include<stdio.h>

int Callback_1() // Callback Function 1
{
    printf("Hello, this is Callback_1 ");
    return 0;
}

int Callback_2() // Callback Function 2
{
    printf("Hello, this is Callback_2 ");
    return 0;
}

int Callback_3() // Callback Function 3
{
    printf("Hello, this is Callback_3 ");
    return 0;
}

int Handle(int (*Callback)())
{
    printf("Entering Handle Function. ");
    Callback();
    printf("Leaving Handle Function. ");
}

int main()
{
    printf("Entering Main Function. ");
    Handle(Callback_1);
    Handle(Callback_2);
    Handle(Callback_3);
    printf("Leaving Main Function. ");
    return 0;
}

运行结果如下：

Entering Main Function.
Entering Handle Function.
Hello, this is Callback_1
Leaving Handle Function.
Entering Handle Function.
Hello, this is Callback_2
Leaving Handle Function.
Entering Handle Function.
Hello, this is Callback_3
Leaving Handle Function.
Leaving Main Function.

看完上面的代码，我的第一感觉，就是回调函数多此一举，为什么不在主函数中直接调用三个callback函数呢？这样不是更加直接有效吗？后来总觉得回调函数的作用不应该这么简单，于是我再次搜索相关的资料，得到如下结果（关于回调函数的异步机制）：

以下内容取自:https://blog.csdn.net/xiabodan/article/details/47999411?utm_source=copy

我们首先假设有两个程序员在写代码，A程序员写底层驱动接口，B程序员写上层应用程序，然而此时底层驱动接口A有一个数据d需要传输给B，此时有两种方式：
　　　１、A将数据d存储好放在接口函数中，B自己想什么时候去读就什么时候去读，这就是我们经常使用的函数调用，此时主动权是B。
　　　2、A实现回调机制，当数据变化的时候才将通知B，你可以来读取数据了，然后B在用户层的回调函数中读取数据d，完成OK。此时主动权是A。
很明显第一种方法太低效了，B根本就不知道什么时候该去调用接口函数读取数据d。而第二种方式由于B的读取数据操作是依赖A的，只有A叫B读数据，那么B才能读数据。也即是实现了中断读取。
那么回调是怎么实现的呢，其实回调函数就是一个通过函数指针调用的函数。如果用户层B把函数的指针（地址）作为参数传递给底层驱动A，当这个指针在A中被用为调用它所指向的函数时，我们就说这是回调函数。
注意：是在A中被调用，这里看到尽管函数是在B中，但是B却不是自己调用这个函数，而是将这个函数的函数指针通过A的接口函数传自A中了，由A来操控执行，这就是回调的意义所在。
下面就通过一个例子来演示
首先写A程序员的代码

//-----------------------底层实现A-----------------------------
typedef void (*pcb)(int a); //函数指针定义，后面可以直接使用pcb，方便
typedef struct parameter{
    int a ;
    pcb callback;
}parameter; 

void* callback_thread(void *p1)//此处用的是一个线程
{
    //do something
    parameter* p = (parameter*)p1 ;
    while(1)
    {
        printf("GetCallBack print! \n");
        sleep(3);//延时3秒执行callback函数
        p->callback(p->a);//函数指针执行函数，这个函数来自于应用层B
    }
}

//留给应用层B的接口函数
extern SetCallBackFun(int a, pcb callback)
{
    printf("SetCallBackFun print! \n");
    parameter *p = malloc(sizeof(parameter)) ; 
    p->a  = 10;
    p->callback = callback;

    //创建线程
    pthread_t thing1;
    pthread_create(&thing1,NULL,callback_thread,(void *) p);
    pthread_join(thing1,NULL);
}

上面的代码就是底层接口程序员A写的全部代码，留出接口函数SetCallBackFun即可

下面再实现应用者B的程序，B负责调用SetCallBackFun函数，以及增加一个函数，并将吃函数的函数指针通过SetCallBackFun(int a, pcb callback)的第二个参数pcb callback 传递下去。

//-----------------------应用者B-------------------------------
void fCallBack(int a)       // 应用者增加的函数，此函数会在A中被执行
{
    //do something
    printf("a = %d\n",a);
    printf("fCallBack print! \n");
}


int main(void)
{
    SetCallBackFun(4,fCallBack);

    return 0;
}

运行程序会看到

先会打印A程序的                 printf("GetCallBack print! \n");
然后等待3秒钟才会打印应用者B的    printf("fCallBack print! \n");

 

 从上面的内容来看，给我最大的体会就是：回调函数带来的好处就是主动权的问题。比如在单片机使用串口和4G模块进行通信的时候，再也不用一直循环或中断模式来等待4G模块上报URC了，我们可以使用回调函数来随时处理AT指令回复的信息。

但回调的优点仅仅如此吗？

通过在技术群的讨论，总结后我获得了一个新的关键词：解耦合。

程序设计经常提到的解耦，到底是要解除什么之间的耦合？我知乎了一下，有的人说解耦就是将程序积木化，各个积木可以组合在一起而形成一个形状，又可以拆分，又可以替换，因为基本上各个积木块都是独立的，只要他们直接的接口（形状）匹配，就可以灵活的组合在一起。当然，这是理想状态。解耦就是在逐渐达到这个理想状态。但有个人的说法让我醍醐灌顶：少用全局变量。

我每次写代码的时候，写之前虽然会先设计框架，保证代码的耦合性，但是为了图方便，后期写代码的时候还是会慢慢的添加各种全局变量，因为不管是在linux的多线程中还是freertos/ucos的任务中，全局变量都是共享的，可以直接拿来用（前提是保证同一时刻只有一个线程/任务修改全局变量）。随着全局变量越来越多，当程序出现bug的时候，问题就来了：牵一发而动全身。

总结：在实现产品功能的时候，务必也要注意代码的耦合性，写好代码，而不是写完代码。