Различий в производительности нет. Использование системы событий может быть намного более эффективным и удобным. Предположим, вы хотите, чтобы что-то происходило в программе, когда вы хотите, чтобы DoSomething прекратил работу, просто отмените подписку на событие.
Class2.OnSomeEvent -= DoSomething;
Другой сценарий, предположим, что ваш старший разработчик хочет, чтобы Class3.SomethingMore и Class4.AnotherThing происходили тоже , Вместо того, чтобы связывать их с методом DoSomething, они также могут просто подписаться на событие с многоадресной рассылкой.
// in Class 3 OnEnable
Class2.OnSomeEvent += SomethingMore;
// in Class 4 OnEnable
Class2.OnSomeEvent += AnotherThing;
Теперь OnSomeEvent запустит все три события. Система делегатов делает ваш код намного более читабельным, модульным и более легким для отладки, поскольку ваша программа становится больше и сложнее. Вы можете подписывать методы на важные события в вашей игре, вместо того чтобы создавать длинные, трудно читаемые цепочки вызовов методов, которые трудно go вернуть и внести изменения. Как правило, Unity спроектирован так, чтобы быть максимально модульным с его Компонентной системой, а система событий делегатов - это способ сделать вызовы методов модульными. Можно также сказать, что есть дополнительный бонус классов, которым не нужны ссылки на другие классы и разрешения для их методов, когда другие классы подписываются на событие.
Чтобы добавить еще один пример, допустим, вы не использовали система событий и прямо сейчас у вас были разные классы, которые периодически вызывались.
Class1.DoSomething();
Ваш старший разработчик говорит вам, что всякий раз, когда вызывается DoSomething (), необходимо вызывать SomethingMore () и AnotherThing (). Вы можете просмотреть код и попытаться найти все места, где вызывается DoSomething (), и добавить две строки после SomethingMore () и AnotherThing () и убедиться, что вызывающие классы имеют ссылки на Class3 и Class4. Другой вариант - добавить ссылки на эти классы в Class1, а в конце метода DoSomething () добавить SomethingMore () и AnotherThing (). Проблема в том, что если позже ваша команда выяснит, что DoSomething () должен вызываться в некоторых случаях сам по себе без SomethingMore () и AnotherThing (), теперь ваш код начнет становиться уродливым.
Наконец, Допустим, вы создаете экземпляры «Bug» врагов, которые будут Swarm (), когда королева приказывает им. Не существует постоянного количества «баговых» врагов, так как некоторые появляются случайным образом и уничтожаются игроком. В скрипте Bug для каждой ошибки гораздо проще подписаться на событие королевы SwarmCommand, чем в скрипте Queen, когда вызывается SwarmCommand для поиска ссылок на каждую ошибку и вызова ошибки Swarm. () '(Вам нужно было бы вызвать FindObjectsWithTag или сохранить актуальный массив всех объектов Bug GameObject, к которым будут добавлены некоторые расходы).