java的回调和C#的委托

曾经有人对我说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#最有趣的地方。