Делегати срещу интерфейси в 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):

Както делегатите, така и интерфейсите позволяват на дизайнера на класове да разделя декларациите на типове и изпълнението. Даден интерфейс може да бъде наследен и имплементиран от всеки клас или структура. Делегат може да бъде създаден за метод във всеки клас, стига методът да отговаря на сигнатурата на метода за делегата. Интерфейсна препратка или делегат може да се използва от обект, който няма познания за класа, който имплементира интерфейса или делегатния метод. Предвид тези прилики, кога дизайнерът на клас трябва да използва делегат и кога трябва да използва интерфейс?

Използвайте делегат при следните обстоятелства:

• Използва се шаблон за проектиране на събития.
• Желателно е да се капсулира статичен метод.
• Извикващият няма нужда да осъществява достъп до други свойства, методи или интерфейси на обекта, изпълняващ метода.
• Желателна е лесна композиция.
• Един клас може да се нуждае от повече от едно изпълнение на метода.

Използвайте интерфейс при следните обстоятелства:

• Има група от свързани методи, които могат да бъдат извикани.
• Един клас се нуждае само от една реализация на метода.
• Класът, използващ интерфейса, ще иска да прехвърли този интерфейс към друг тип интерфейс или клас.
• Методът, който се прилага, е свързан с типа или идентичността на класа: например методи за сравнение.

Един добър пример за използване на интерфейс с един метод вместо делегат е IComparable или общата версия, IComparable(Of T). IComparable декларира метода CompareTo, който връща цяло число, което указва връзка по-малко от, равно на или по-голямо от между два обекта от един и същи тип. IComparable може да се използва като основа на алгоритъм за сортиране. Въпреки че използването на метод за сравнение на делегати като основа на алгоритъм за сортиране би било валидно, това не е идеално. Тъй като възможността за сравнение принадлежи на класа и алгоритъмът за сравнение не се променя по време на изпълнение, интерфейсът с един метод е идеален.

От Делегати срещу интерфейси в 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 поддържаше генерични кодове от самото начало, делегатите нямаше да са необходими, освен за определени сценарии, включващи Reflection, и дори там може би щеше да е най-полезно типът Action<T,U> да бъде реализация на IAction<T,U> (така че кодът, който просто се нуждае нещо, което може Invoke би използвало интерфейса). Подход, базиран на интерфейс, би изисквал създаването на класове с един метод в случаите, когато класовете трябва да създадат делегати, излагащи множество методи, но би премахнал необходимостта от създаване на отделни екземпляри на делегати в много често срещани случаи, когато броят на методите на даден подпис да бъде изложен е точно един.

Между другото, замяната на делегатите с интерфейси по никакъв начин няма да попречи на създаването на метод за комбиниране с общо предназначение. Наистина ковариацията на интерфейса може да направи такъв метод да работи по-добре от съществуващия Delegate.Combine в много отношения. Прилагането на метод, аналогичен на Delegate.Remove, би било в най-добрия случай тромаво и досадно, но не мога да се сетя за друга ситуация освен управлението на абонамент за събития, която да изисква използването на Delegate.Remove, а абонаментът за събития може да се управлява най-добре с други подходи така или иначе.