Block_callBack VS Protocal_Delegate
————————
从实现步骤上看
block 函数指针,是通过函数指针调用方式实现调用逻辑,代码实现上相对简单。
protocol 协议代理,需要通过协议代理,明显的代理设计模式,代码上相对较繁。
如果是传值使用,两个对象之间其实都是需要有对应的关联。
block 通过函数指针 持有调用进行关联
protocol,通过设置delegate,遵循协议进行关联
1. block函数的实现块一般写在持有对象AObj初始化的地方,而这个持有对象存在于另一个BObj。AObj通过函数 指针 调用thisBlock,而thisBlock的实现块是在BObj中(BObj { thisBlock = ^{ implement } })
2. 如果使用Protocol,AObj中需要用到一个事先声明好的协议(为了方便协议可以直接写在Aobj的头文件中), AObj需要持有一个该协议的代理对象(id<protocalDelegate>)属性。如果AObj.delegate is BObj,那么在AObj 可以通过协议代理调用协议中的方法protocal,而这个代理对象就是BObj。
3. 综上两点看来,block和协议代理都是讲函数调用 和 函数的实现分割在不同的对象中,从而利用这个特殊的函数 实现两个对象之间通讯。
4. 在使用中,block代码其实会感觉简单紧凑很多,然而不绝对,如果BObj中有许多AObj,而且这些AObj并不能 设计成一个循环体系中的初始化实现,那么要实现的block块也会多起来,如果是这样子其实代码量反而增加了。 与之对比,如果使用协议代理,协议方法只用一个可以,只需要每一处都有AObj.delegate = BObj一行代码就好 了。
5. 由上可以分析,大概能够看出使用哪个更方便需要根据具体设计来考量。使用block会存在需要处理好循环引用的 问题,由于是直接C的函数方式,效率应当是比协议要高的。有的时候代码紧凑一点的感觉会使得逻辑更清晰。 然而代码耦合的处理,个人感觉协议代理能够处理的更好。两个机制各有优势。
6. 当然,block与协议代理不同,block可以说是处处都可以存在,强调的还是函数指针的使用,在同一个兑现OObj 中同样可以使用block,协议却是专门为了实现两个对象之间的通讯而设计的。
7. 从现有的框架和实践中可以得出结论,二者都不能抛弃,block无处不在。也许一般的应用,更多使用到的 是block。协议代理更能体现设计模式思想的强大之处。
补充:
coding的时候容易遇到一个左右为难的问题,到底该使用哪个方式比较好呢,也许很多时候回情不自禁的就用了 typedef returnType (^ Blockname ) ( arguments ); 一般情况并没什么问题,不过停下来稍稍思考一下,真的 在当下这个场景使用它会更简洁,更优雅? 如果protocal能够更好的完成任务,那就果断使用protocal吧。