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#最有趣的地方。