曾经有人对我说java的回调很巧妙。
今天我自己看了一下,回调的关键就是一个接口的事情。
也许是因为用了一定的手法,一开始不好懂吧,所以看懂了会感觉巧妙。
但是我心里的想法却是,真啰嗦!
回调的实例
下面是一个回调的实例,截图自网友的文章----https://www.jianshu.com/p/2cbc5232547a。
意思就是,我提前定义了CallBack接口,里面预先约定了giveMe这一行为。
然后Buyer内部有个继承自CallBack的成员,需要在一个方法中传入这个CallBack实例。
Buyer内部有个方法会做一些事情,做完了呢?就会做执行约定好的giveMe行为。
然后Me呢?通过一个匿名内部类实现了CallBack接口,Override了giveMe行为。
这样以后Buyer执行完doThing方法后,就会执行giveMe行为。
本质是什么呢?
本质是动态的替换Buyer类的giveMe行为。
这个本质是语法层面上的。
C#怎么写?
我想让GiveMe方法是活的?那我就放上一个GiveMe方法的指代物----名字也叫GiveMe。
Me想改变Buyer实例的GiveMe行为?给GiveMe这个委托赋值一下就好了。
很明显,使用委托是更加简单直接的做法,更直觉式的。
本质
大家都差不多其实,大家的本质都是一个指针。
大家都是一个【方法引用】的指针指向了【被调用的方法】。
这个本质是原理层面的。
有意思的地方
使用接口的一个好处是,抽出不一样的地方单独修改。也就是光改不一样的地方,一样的地方不修改。
所以,一些人就把多态,抽离组合当作面向对象特有的东西。
但是Java使用接口做出来的回调机制,并不能简洁的把当前例子中【每个Buyer实例的GiveMe行为是不同的】这一区别抽离出来。
java要每次多写一个类,然后重写GiveMe方法才可以。最简单的办法当然是,GiveMe不一样,那我只改GiveMe。
文档
刚才查了一下微软文档,微软文档很贴心的说明了何时应该使用委托,何时应该使用接口。
C#当然也可以使用接口来实现这一功能,但是委托好用的时候就用委托了。
下面是截图。
突然想到
今天我工作的时候就想到,很多框架对人的编码工作都是一种限制,都是强制的让人去使用这种方式而不使用另一种方式来写代码。
如果强制让人用什么框架写的话,就会写的很啰嗦。
那为什么不去除这种约束,然后大家商量出一套编码规范来呢??
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
但是回头想了下并不是这样。
就像墨菲定律说的,如果说有两种写法一种好,一种坏,一定有人会用那种坏的方法去写。
我自己也会,因为代码并不是一口气写好的,越写越多就会越来越乱。
目前人们抱怨的java的啰嗦,大部分是因为java死抱住面向对象设计而产生的,我是面向对象的,那我就用面向对象的方式去解决问题,我就有我的套路。
我java并不是死板,而是有自己的特点。
最后
java是架构师的语言,C#是程序员的语言。
C#把复杂的设计隐藏在了简单的语言特性之中;虽然完全面向对象,但不迷信面向对象;不管是函数式/声明式,只要能简化编码工作,只要好用,那我就支持上。
这是C#最有趣的地方。