В чем преимущества делегатов?

Ответ 1

Это отличный способ инкапсулировать кусок кода. Например, когда вы прикрепляете обработчик события к кнопке, этот обработчик является делегатом. Кнопка не должна знать, что она делает, просто как позвонить ей в нужное время.

Еще один пример: LINQ - фильтрация, проецирование и т.д. все требуют одинакового кода шаблона; все эти изменения являются логикой представления фильтра, проекции и т.д. С лямбда-выражениями в С# 3 (которые преобразуются в делегаты или деревья выражений) это делает его очень простым:

var namesOfAdults = people.Where(person => person.Age >= 18)
                          .Select(person => person.Name);

(Это также можно представить как выражение запроса, но не допускать слишком большого отклонения от делегатов.)

Другой способ мышления делегата - это тип интерфейса одного метода. Например, тип делегата EventHandler немного похож:

public interface IEventHandler
{
    void Invoke(object sender, EventArgs e)
}

Но поддержка делегата в рамках позволяет делегатам соединяться вместе, вызывается асинхронно, используется как обработчики событий и т.д.

Подробнее о делегатах и ​​событиях см. мою статью по теме. Его фокус - это события, но он также охватывает делегатов.

Ответ 2

Это довольно неопределенная тема, но вот несколько вещей, которые следует учитывать -

Делегаты - это, в основном, более простой и понятный указатель. В любом месте, где указатели на функции использовались в С++, вы можете подумать о делетете.

Преимущества использования их в дизайне:

• Может привести к простому повторному использованию кода
• Может обеспечить большую гибкость в ваших проектах.
• Позволяет создавать библиотеки и классы, которые легко расширяемы, поскольку он обеспечивает простой способ подключения к другим функциям (например, предложение where в LINQ может использовать делегат [Func<T,bool>] для фильтрации, без необходимости писать новый код в методе Where

Потенциальные недостатки:

• Они ~can~, особенно если они используются наивно, приводят к более сложному чтению кода
• Они могут ввести поведение в ваш компонент, что является неожиданным, так как вызывается вызывающий код из вашего элемента управления (например, если кто-то присоединяет делегата к одному из ваших событий, который вызывает бесконечный цикл, он может сделать ваш класс выглядите плохо, хотя это не имеет никакого отношения к вам)

Ответ 3

Делегаты выполняют три цели:

• Упрощенная реализация шаблона Observer
• Упрощенная реализация обратных вызовов
• Анонимные (непеременные) блоки кода

наблюдатель

public class Something
{
    public event EventHandler SomethingHappened;
}

public class SomethingConsumer
{
    private mySomething = new Something();

    public void WireUpEvents()
    {
        mySomething.SomethingHappened += whenSomethingHappened;
    }

    private void whenSoemthingHappened(object sender, EventArgs e)
    {
        // do something
    }
}

CallBack

public void DoSomethingAsynchronously(EventHandler callBack)
{
    // long running logic.
    callBack(this, EventArgs.Empty);
}

Анонимный код без повторного использования

public void DoSomethingReusably(Action nonReusableCode)
{
    // reusable code
    nonReusableCode();
    // more reusable code
}

public void DoALotOfSomething()
{
    DoSomethingReusably(() => { /* non-reusable code here */ });
    DoSomethingReusably(() => { /* non-reusable code here */ });
    DoSomethingReusably(() => { /* non-reusable code here */ });
}

Во всех случаях это просто вопрос обеспечения консистенции.

Ответ 4

Делегировать в С# является eqv. для функции указателя в C, но также содержит ссылку на экземпляр класса, из которого он был создан.

Все обработчики событий в Windows Forms являются делегатами.

Ответ 5

Преимущества по сравнению с чем? Делегаты могут быть полезными и, безусловно, иметь свое место во множестве довольно сложных С# -кодов. (Всякий раз, когда вы используете события в классах, вы неявно используете многоадресные делегаты). Если вы хотите ознакомиться с их синтаксисом и использованием, я рекомендую следующие статьи:

• Учебное пособие по MSDN
• Введение в делегаты - статья журнала MSDN

Ответ 6

Отказ от ответственности: я не говорю, как я использовал делегат, это намеченный путь, но это пример.

Я использовал его только один раз, но в основном в нашем приложении пользователь нажимает кнопку "Завершить" для шага, который затем переводит их на страницу маршрутизации, чтобы решить, куда ее отправить дальше. Так что технически шаг, который они только что нажали "Завершить" , на самом деле не закончен, пока он не набросит его. Но поскольку я на другой странице, мне нелегко было получить доступ к тому, где они были.

Итак, что я сделал, был создан делегат для нескольких шагов, требующих специальной обработки (в этом случае электронной почты), когда нажал "Завершить" , и когда они перенаправили его на следующей странице, я бы проверил наличие делегат, и если он там был, позвоните, чтобы запустить мое "сохраненное" событие.

Креатив: возможно, неправильно: возможно, работает: определенно.

Как я уже сказал, вероятно, не то, как он должен был использоваться, но кодирование - это такое же искусство, как и наука?

Ответ 7

Я помню раннюю инфраструктуру графического интерфейса Java, которая не имела понятия делегатов или маршрутизации команд. Чтобы сделать кнопку, которая что-то делает, вам нужно подклассировать Button и переопределить метод щелчка. В итоге у вас много и много подклассов элементов пользовательского интерфейса с небольшим количеством кода вашего приложения.

Код, который обрабатывает этот клик, должен куда-то уходить, а на языке OO, таком как Java или С#, он должен идти в классе, но делегаты позволяют это происходить в удобном месте. Это часто приводит к тому, что слишком много кода делает слишком много разных вещей в классе формы, но это другая проблема.