博文技术有限，重在学习交流，有错误大家指正。
思路：
传统的方法调用------>委托的出现解决了什么问题---->委托的绑定方法----->总结
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
这样是不是 简便很多了？
注：这里有个多播委托的小细节，+=必须委托第二个方法的时候使用，第一委托必须是=，不然会出现未赋值的错误。
也可以使用-= 符号取消委托。
总结：博文技术有限，写的有错误大家指正，从 为什么需要委托，认识到了 委托其实就是一个 定义方法类型的类，到 简化代码实现了委托绑定了方法。
