我想请教一下unity的事件的正确用法是什么，一直不懂该用在什么地方，这里我写了个开门的例子，用了event代码还长了，虽然说没长多少，就还例如一个PVE游戏玩家达到多少多少分就gameover，在这里就可以写一个if判断语句判断玩家是否到达指定分数，如果用事件的话感觉有点过于麻烦了，这里我就感觉所有的：当.....后执行....，这些都可以用判断来解决，所以请大佬们指点一下我event该用在什么地方
写法一：
写法二：

大佬们我在补一点：就是当.....后执行....，这些都可以用判断来解决，后续在Update里直接该Destroy的Destroy，类似只执行一遍，然后就执行后续操作，所以就不是很懂事件该用在哪里，是不是写事件会优雅点

去看看监听者模式

1. 事件不是如果怎样就执行什么的逻辑判断，他是触发调用一个函数指针的列表，通俗说就是按序执行一堆函数，跟if没有卵关系，不要思维混乱
2. 事件只管触发，而不管触发后要具体执行哪些逻辑，调用处对外界要做什么一无所知，这就是解耦合，发个通知就完了，谁订阅，做了什么与我无关，比如开火事件，具体是开火还是游泳，事件根本不关心，他只是挨个执行一下那个函数列表里的每个函数
3. 事件可以运行时动态注册，这就可以做动态的逻辑组合，而不是写死要执行的逻辑，比如你做一个任务栈系统，动态的添加和移除要执行的任务代码

其实事件优缺点都有，优点是解耦，缺点是不直观不易调试。多人协作的项目肯定要用，不然耦合高到没法干

放在需要接受的地方

要看什么皮，不同的皮革封边方法也不同

委托我没用过，我用的System.Action 比较多。相当于委托的升级版。
首先你要知道为什么要用委托。委托的目的是解耦，减少引用。比如A对象要调用B对象的一个方法，那么传统的写法是在A里写：
b.xxx();
这个时候就A就引用B了，看起来没啥问题。但是如果有ABCDEF五个对象，互相调用呢？
非常乱，不面向对象，代码的可拓展性会很差，甚至最后你都没法再加功能，然后BUG非常多，改一个地方非常多的Bug就出现。这时候就要用各种面向对象的方法来解决。比如委托就是一种方法（C#是OOP的语言，有很多OOP特性，委托是其中一种）
用了委托，那么A就不用引用B，你可以创造一个W对象，所有的委托都在W里。如果A想调用B里的方法，A需要写 W.xx委托(); ，B去监听这个委托，那么ABCDEF都不用互相引用了，他们都引用W就可以了，这就是一种解耦