本文主要是介绍回调函数引发的自省,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
每次看到回调函数我都会纠结一下,因为我不会。尽管每次都会重新学习一遍,但是从来没用过,过几天就会忘记。经常看到别人说回调函数好用,今天就再次从网上学习了一遍回调函数。看完之后,觉得回调函数...就这?附段学习网站的代码:
#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,此时有两种方式:
1、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 somethingparameter* 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 somethingprintf("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的时候,问题就来了:牵一发而动全身。
总结:在实现产品功能的时候,务必也要注意代码的耦合性,写好代码,而不是写完代码。
这篇关于回调函数引发的自省的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!