2015-07-28 2 views
4

Я проделал честное чтение, и я нахожусь на том этапе, когда я начинаю понимать, что они делают, но я в недоумении, когда дело доходит до того, почему и где я буду использовать их , В каждом примере я видел, что повторяющееся определение похоже как указатель метода, и вы можете использовать это вместо вызова метода, который, по-видимому, полезен, когда разработчик не знает, какой метод для вызова или выбора метод основан на состоянии или состоянии.Понимание точки делегатов на C#

Здесь я немного борюсь, почему я не могу просто иметь оператор if или оператор switch, а затем вызывать метод напрямую на основе результата? Что плохого в вызове метода непосредственно из экземпляра объекта? По моему мнению, делегат предлагает лучший способ сделать это, но я не могу понять, что лучше об этом, с моей точки зрения, это всего лишь круглый способ достичь того же, что и оператор if, когда вы решаете, какой метод вызывать.

Я нахожусь в растерянности и сейчас немного болтаю, всякая помощь по этому вопросу была бы очень признательна!

+0

Возможный дубликат [Где использовать делегаты?] (Http://stackoverflow.com/questions/31497/where-do-i-use-delegates) – JasonWilczak

+1

Много раз вы * не знаю, какой метод вызывать. Например, метод Sort не знает критерии, по которым вы хотите заказать коллекцию объектов. В этом случае вы можете передать указатель на функцию, которая получает два объекта и решает, что происходит первым. Другим случаем являются обработчики событий - вы не знаете, кто будет подписываться на события, поэтому вы разрешаете абонентам регистрировать делегатов, что ваш код будет, когда это необходимо –

+1

Ну, делегаты сокращают код. Я использую клиент Android для публикации, поэтому я не знаю, будет ли это отображаться как SO-код. В любом случае, например, посмотрите на этот Dispatcher.Invoke ((Action) delegate {// stuff here}); Он использует меньше байтового пространства и легко читается. У него есть и другие преимущества, не говоря о них, поскольку я использую Android-клиент, я считаю, что кто-то даст прекрасный ответ на это. – TuukkaX

ответ

3

Почему я не могу просто иметь оператор if или оператор switch, а затем вызывать метод напрямую на основе результата?

Это было бы хорошо, если бы у вас было 2 или 3 разных ветви и методы. Теперь представьте, что у вас есть десятки или сотни методов, которые могут быть потенциально вызваны в зависимости от ситуации. Я бы не хотел быть тем, кто напишет это утверждение if.

Представьте, что у персонажа есть 100 различных потенциальных способностей. Каждая способность может иметь свой собственный метод для выполнения. В зависимости от того, какие способности у игрока есть, вы можете просто бросить эти методы в список для этого символа, используя делегатов. Теперь его полностью настраиваемые возможности и возможности игрока не записаны в коде, и их можно легко или просто взять в руки или потерять в ходе игры, и могут быть тысячи способностей, не говоря уже о количестве потенциальных комбинации.

2

Подумайте об этом таким образом. Согласно SOLID принципу OOD (например), каждый объект должен нести ответственность за одну часть функциональности. Используя этот принцип, можно предположить, что:

Занятия ответственны за работу с пользовательскими объектами, structs with - наборы данных, методы отвечают за действия, события ответственны за сигнализацию о том, что что-то происходит, и делегаты несут ответственность за соответствующее действие о событиях, которые должны произойти.

Мероприятия и методы «заняты» с их собственной частью функциональности и, следовательно, не могут обрабатывать сами события и нести ответственность за методы. Вот почему нам нужны делегаты ...

Смежные вопросы