Создание делегатов вручную или использование делегатов Action / Func

Преимущество - ясность. Если дать типу явное имя, читателю будет более понятно, что он делает.

Это также поможет вам при написании кода. Такая ошибка:

cannot convert from Func<string, int, double> to Func<string, int, int, double>

менее полезен, чем тот, в котором говорится:

cannot convert from CreateListAction to UpdateListAction

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

С появлением семейств делегатов Action и Func пользовательские делегаты стали менее использоваться, но последние по-прежнему находят применение. К преимуществам настраиваемых делегатов относятся:

1. Как указывали другие, явно выражает намерение, в отличие от общих Action и Func (Patrik имеет очень хорошее замечание о значимых именах параметров).

2. Вы можете указать _5 _ / _ 6_ параметров в отличие от двух других универсальных делегатов. Например, вы можете иметь

   public delegate double ChangeListAction(out string p1, ref int p2);
   

   но нет

   Func<out string, ref int, double> ChangeListAction;
   

3. Кроме того, с настраиваемыми делегатами вам нужно написать ChangeListAction (я имею в виду определение) только один раз где-то в базе кода, тогда как, если вы не определите его, вам придется мусорить везде Func<string, int, double> повсюду. В последнем случае поменять подпись будет хлопотно - плохой случай не высохнуть.

4. Могут иметь необязательные параметры.

   public delegate double ChangeListAction(string p1 = "haha", int p2);
   

   но нет

   Func<string, int, double> ChangeListAction = (p1 = "haha", p2) => (double)p2; 
   

5. Вы можете использовать ключевое слово params для параметров метода, но не Action/Func.

   public delegate double ChangeListAction(int p1, params string[] p2);
   

   но нет

   Func<int, params string[], double> ChangeListAction;
   

6. Что ж, если вам действительно не повезло и вам нужны параметры больше 16 (пока что) :)

Что касается достоинств Action и Func:

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

2. Что еще более важно, его тип совместим с разными доменами. Action и Func определены структурой, и они работают без сбоев, пока типы параметров совпадают. Вы не можете получить ChangeSomeAction за ChangeListAction. Linq находит большое применение в этом аспекте.

Явное объявление делегата может помочь с некоторыми проверками типов. Компилятор может убедиться, что делегат, назначенный переменной, предназначен для использования в качестве ChangeListAction, а не как какое-то случайное действие, которое оказывается совместимым с подписью.

Однако реальная ценность объявления собственного делегата в том, что оно придает ему семантическое значение. Человек, читающий код, будет знать, что делает делегат, по его имени. Представьте, что у вас есть класс с тремя полями int, но вместо этого вы объявили массив из трех элементов int. Массив может делать то же самое, но имена полей несут семантическую информацию, полезную для разработчиков.

Вы должны использовать делегаты Func, Predicate и Action при разработке библиотеки общего назначения, такой как LINQ. В этом случае делегаты не имеют предопределенной семантики, кроме того факта, что они будут выполняться и действовать или использоваться в качестве предиката.

С другой стороны, существует аналогичная проблема компромисса с Tuple против анонимного типа и объявления вашего собственного класса. Вы можете просто вставить все в кортеж, но тогда свойства будут просто Item1, Item2, которые ничего не говорят об использовании типа.

Поскольку в некоторых ответах упоминается, что победа - это ясность, вы называете тип, и поэтому пользователю вашего api будет легче понять. Я бы сказал - в большинстве случаев - объявляйте типы делегатов для ваших общедоступных API, но вполне нормально использовать Func<?,?> для внутренних целей.

Одно огромное преимущество объявления типа делегата, которое не упоминается в других ответах, заключается в том, что помимо присвоения типу имени, которое вы фактически получаете для именования параметров, это значительно повысит удобство использования.

Я нашел особый вариант использования, в котором можно использовать только делегат:

public delegate bool WndEnumProc(IntPtr hwnd, IntPtr lParam);
[DllImport("User32.dll")]
public static extern bool EnumWindows(WndEnumProc lpEnumFunc, IntPtr lParam);

Использование Func / Action просто не работает: 'Namespace.Class.WndEnumProc' is a 'field' but is used like a 'type':

public Func<IntPtr, IntPtr, bool> WndEnumProc;
[DllImport("User32.dll")]
public static extern bool EnumWindows(WndEnumProc lpEnumFunc, IntPtr lParam);

Следующий код компилируется, но выдает исключение при запуске, потому что System.Runtime.InteropServices.DllImportAttribute не поддерживает маршалинг универсальных типов:

[DllImport("User32.dll")]
public static extern bool EnumWindows(Func<IntPtr, IntPtr, bool> lpEnumFunc, IntPtr lParam);

Я представляю этот пример, чтобы показать всем, что: иногда делегат - ваш единственный выбор. И это разумный ответ на ваш вопрос why not use Action<T>/Func<T> ?

Объявите делегат явно, когда вы начнете получать слишком много параметров в Func / Action, иначе вам придется оглядываться назад: «Что снова означает второй int?»

Чтобы получить лучший и более подробный ответ, посмотрите @nawfal. Я постараюсь быть более упрощенным.

Вы объявляете член класса, поэтому вам следует придерживаться делегата. Использование delegate более наглядно и структурно.

Action/Func типы предназначены для передачи, поэтому вы должны использовать их больше как параметры и локальные переменные.

И на самом деле оба они наследуют Delegate класс. Action и Func являются универсальными типами и упрощают создание делегатов с разными типами параметров. А ключевое слово delegate фактически создает целый новый класс, унаследованный от Delegate в одном объявлении.

Как сказано в MSDN, Func<> сам по себе предопределенный Delegate. Впервые я запуталась в этом. После эксперимента мое понимание стало более ясным. Обычно в C # мы видим

Type как указатель на Instance.

Та же концепция применяется к

Delegate как указатель на Method

Разница между этими вещами в том, что Delegate не владеют концепцией ООП, например, Inheritance. Чтобы прояснить ситуацию, я провел эксперимент с

public delegate string CustomDelegate(string a);

// Func<> is a delegate itself, BUILD-IN delegate
//==========
// Short Version Anonymous Function
Func<string, string> fShort = a => "ttt";
//----------
// Long Version Anonymous Function
Func<string, string> fLong = delegate(string a)
{
  return "ttt";
};
//----------
MyDelegate customDlg;
Func<string, string> fAssign;
// if we do the thing like this we get the compilation error!!
// because fAssign is not the same KIND as customDlg
//fAssign = customDlg;

Многие встроенные методы в фреймворке (например, LINQ) получают параметр делегата Func<>. Что мы можем сделать с помощью этого метода, так это

Declare делегат типа Func<> и передать его функции, а не Define пользовательскому делегату.

Например, из приведенного выше кода я добавляю еще код

string[] strList = { "abc", "abcd", "abcdef" };
strList.Select(fAssign); // is valid
//strList.Select(customDlg); // Compilation Error!!