Цель делегатов [дубликат]

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

public delegate Duck GetDuckDelegate();

public GetDuckDelegate GiveMeTheDuckFactoryMethod(string type)
{
  switch(type)
  {
    case "Rubber":
      return new GetDuckDelegate(CreateRubberDuck);
    case "Mallard":
      return new GetDuckDelegate(CreateMallardDuck);
    default:
      return new GetDuckDelegate(CreateDefaultDuck);
  }
}

public Duck CreateRubberDuck()
{
  return new RubberDuck();
}

public Duck CreateMallardDuck()
{
  return new MallardDuck();
}

public Duck CreateDefaultDuck()
{
  return new Duck();
}

Затем использовать его

public static void Main() {
  var getDuck = GiveMeTheDuckFactoryMethod("Rubber");
  var duck = getDuck();
}

Возможно, Шаблон "фабрика" был бы лучшим методом для этого, но я просто продумал этот пример на лету и думал, что он подтвердил точку зрения того, как делегатов можно рассматривать как объекты

Делегаты позволяют Вам раздавать методы как значения.

Например, .NET назвали метод Array.ForEach это берет делегата и массив, и звонит делегату на каждом элементе массива.

Поэтому Вы могли записать,

int[] arr = new int[] { 1, 2, 4, 8, 16, 32, 64 };
Array.ForEach(arr, new Action<int>(Console.WriteLine));

Этот код будет звонить Console.WriteLine для каждого числа в массиве.

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

Я могу предоставить Вам пример с помощью архитектуры веб-приложения:

Обычно с веб-приложением можно обеспечить фронтальный контроллер, который получает запросы от многих клиентов. Мы могли поместить все наши методы во фронтальном контроллере для контакта со многими различными типами запросов от клиентов. Однако это становится немного громоздким. Вместо этого мы можем использовать делегатов для инкапсуляции функциональности для различных запросов. Мы могли иметь:

• Делегат аутентификации
• Делегат управления пользователями

и так далее. Таким образом, это - аккуратный способ разделить функциональность на логические блоки - делегаты. Платформа Struts основана на этом способе работать (классы ActionServlet и Действия).

Существует много превосходных статей, объясняющих, что делегаты - вот являются некоторыми хорошими:

Делегаты и события
Объясненные делегаты C#
Делегаты в C#

Делегаты, к моему пониманию, дают возможность специализации поведения класса, не разделяя его на подклассы.

Некоторые классы имеют сложное универсальное поведение, но все еще предназначены, чтобы быть специализированными. Думайте о классе Окна в платформе GUI: Окно может propably сделать много на своем собственном, но Вы, скорее всего, все еще хотели бы специализировать его в некотором роде. В некоторых платформах это сделано через наследование. Другой способ сделать его с делегатами. Скажите, что Вы хотите, чтобы что-то произошло, когда Окно изменяет размер: Ваш класс делегата может затем реализовать метод, названный onWindowResize (обеспечил, конечно, что класс Окна поддерживает это), который называют каждый раз, когда Окно изменяет размер и ответственно за любое специализированное поведение, когда Окно изменяет размер.

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

Многие люди сначала путаются с реальной потребностью в делегатах и ​​событиях. Я был одним из них, и мне потребовалось время, чтобы понять это :-). Недавно ответил на аналогичный запрос на форумах ASP.NET и подумал, что было бы хорошо, если бы я создал сообщение в блоге по этой теме! Здесь был запрос:

«Я где-то читал пример класса банка, в котором, если достигнут минимальный баланс, вам нужно сообщить остальной части приложения, что минимальный баланс достигнут, но мы не можем сделать это просто вызов обычного метода. ОС не заботится, кто фиксирует это событие и использует его, она просто отправляет уведомление. Тогда любой код (например, наш) может зафиксировать это событие и использовать его соответствующим образом. Это экономит нам много времени, чтобы писать код для себя. И другие программы тоже могут использовать то же событие и обрабатывать его соответствующим образом.

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

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