Делегаты против интерфейсов в C #

Да, делегаты во многом похожи на интерфейсы с одним методом. Тем не мение:

• Для них в CLR встроена поддержка.
• Для них есть поддержка в структуре, включая возможности многоадресной передачи и асинхронный вызов.
• Есть дополнительная поддержка языка C # / VB в виде преобразований групп методов, лямбда-выражений, анонимных методов.
• Они обязательны для событий (т.е. события и делегаты представляют собой своего рода совпадающую пару)
• Они означают, что вам не нужно реализовывать интерфейс в отдельном классе для каждого экземпляра делегата, который вы хотите создать.

Последний пункт является наиболее важным - рассмотрите LINQ-выражение:

var query = collection.Where(x => x > 5)
                      .Select(x => x * x);

А теперь представьте, что если бы для выражения логики x > 5 и x * x вам пришлось бы написать отдельный класс для каждого выражения и реализовать интерфейс: количество бесполезного и полезного кода было бы смешным. Конечно, язык мог быть разработан для преобразования лямбда-выражений в реализации интерфейса через отдельные классы, но тогда вы все равно потеряете возможность просто написать отдельный метод и создать делегировать с этим в качестве цели. Вы также все равно потеряете многозадачные способности.

В качестве аналогичного упражнения рассмотрите зацикленные операторы, такие как while и for. Действительно ли они нам нужны, когда у нас есть goto? Неа. Но с ними жизнь намного лучше. То же самое и с делегатами, а также с свойствами, событиями и т. Д. Все они упрощают разработку.

Самое большое практическое отличие состоит в том, что вы можете предоставить разные экземпляры делегата для одного и того же делегата из одного и того же класса, в то время как вы не можете сделать это с помощью интерфейсов.

delegate void XYZ(int p);

interface IXyz {
    void doit(int p);
}

class One {
    // All four methods below can be used to implement the XYZ delegate
    void XYZ1(int p) {...}
    void XYZ2(int p) {...}
    void XYZ3(int p) {...}
    void XYZ4(int p) {...}
}

class Two : IXyz {
    public void doit(int p) {
        // Only this method could be used to call an implementation through an interface
    }
}

Из Когда использовать делегатов вместо интерфейсов (MSDN) < / а>:

Из Делегаты против интерфейсов в C #:

Делегаты и интерфейсы - это две разные концепции в C #, но у них есть общая черта. И делегаты, и интерфейсы включают только объявление. Реализация осуществляется другим программным объектом.

Делегаты и интерфейсы - это два разных понятия в C #.

Интерфейсы позволяют расширить функциональность некоторых объектов, это договор между интерфейсом и объектом, который его реализует, в то время как делегаты - это просто безопасные обратные вызовы, они представляют собой своего рода указатели на функции.

Единственные реальные преимущества делегатов перед интерфейсами:

1. Delegates could deal with different argument types even before .Net supported generics.
2. A class can create delegates exposing multiple different methods sharing the same signature; replacing delegates with interfaces would mean that every class could expose one method that implemented each delegate-style interface without creating helper classes, but would need a helper class for each additional implementation.

Когда .net не поддерживал дженерики, делегаты были его неотъемлемой частью, поскольку объявление отдельных неуниверсальных интерфейсов для каждой отдельной сигнатуры функции, которую хотелось бы передать, было бы неработоспособным. Если бы .net с самого начала поддерживал дженерики, делегаты не были бы необходимы, за исключением определенных сценариев, связанных с отражением, и даже там, возможно, было бы наиболее полезно, чтобы тип Action<T,U> был реализацией IAction<T,U> (так что этот код, который просто нуждается в что-то, что он может Invoke, использовал бы интерфейс). Подход, основанный на интерфейсе, потребовал бы создания классов с одним методом в тех случаях, когда классам необходимо создавать делегаты, предоставляющие несколько методов, но устранил бы необходимость создания отдельных экземпляров делегата во многих распространенных случаях, когда количество методов одного данная подпись будет выставлена ​​именно одна.

Между прочим, замена делегатов интерфейсами никоим образом не помешает созданию универсального метода Combine. Действительно, ковариация интерфейсов могла бы сделать такой метод во многих отношениях лучше, чем существующий Delegate.Combine. Реализация метода, аналогичного Delegate.Remove, была бы в лучшем случае неудобной и раздражающей, но я не могу придумать никакой другой ситуации, кроме управления подпиской на события, которая потребовала бы использования Delegate.Remove, а подписку на события лучше всего обрабатывать с использованием других подходов в любом случае.