抛开书本谈 委托,为什么需要委托,它成就了什么?

博文技术有限,重在学习交流,有错误大家指正。

思路:

传统的方法调用------>委托的出现解决了什么问题---->委托的绑定方法----->总结


1.传统的方法调用

View Code

缺点:100个方法就要调用100次,如果每个人 对方法的需求不一样,就不能很好的处理了。有人想展示跳舞,有人想唱歌,更有想一起展示。

2.引入 枚举试试看
 

View Code

缺点:枚举虽然可以解决根据枚举的项判断出 谁想展示什么才艺,但是扩展性不好。
思考:有没有一种方法,参数内带有:这个人的名字,然后自己想展示什么才艺,就自己带入?
比如:方法(名字,我的才艺)


3.这个时候单播委托出现了
根据 方法(名字,我的才艺),这个类型知道:
名字是 string 类型的,也就是string类
我的才艺 是 方法,但是参数必须是有类型的,所以这里我们可以推断出我们要设计 一个类CLASS,这个类就是所有方法的类型。
注:这里咱们轻易的看出了,委托起始就是定义 方法的类型。

View Code



输出:
Mr.w会跳舞
Jack会唱歌
Herry会跳舞
Herry会唱歌
哈哈,问题解决了,它没有利用switch语句,这样就可以根据不同的人,选择不同的才艺表演了。
有人可能以为这样和写传统的方法调用 有什么区别,你注意到没?你注意到没:每次增加才艺,都必须在PersonCY()方法内修改,这样使用委托带入,即使
我们增加了才艺的方法,也只需要在委托中带入即可。扩展性变优秀了。

注:上面还解决,一个人多个才艺的问题,但是做法不标准,一般我们是利用 多播委托来完成的。


4.多播委托

View Code

思考:看起来还是不简便,能否让 PersonCY()也省略,直接让委托调用方法,答案是可以的。
如下:

View Code


这样是不是 简便很多了?
注:这里有个多播委托的小细节,+=必须委托第二个方法的时候使用,第一委托必须是=,不然会出现未赋值的错误。
也可以使用-= 符号取消委托。


总结:博文技术有限,写的有错误大家指正,从 为什么需要委托,认识到了 委托其实就是一个 定义方法类型的类,到 简化代码实现了委托绑定了方法。

原文地址:https://www.cnblogs.com/xumaojun/p/8541081.html