2010-06-12 6 views
3

Я вижу все более широкое использование типов делегатов, предлагаемых в пространстве имен System (; Predicate<T> и т. Д.). Поскольку это делегаты, я понимаю, что они должны использоваться там, где мы традиционно использовали делегатов в прошлом (асинхронные вызовы, запуск потоков, обработка событий и т. Д.). Это просто предпочтение или считается, что практика использует эти типы делегатов в сценариях, таких как ниже; а не с помощью вызовов методов мы объявленные (или анонимных методов):Использование типов делегатов против методов

public void MyMethod() 
{ 
     Action<string> action = delegate(string userName 
     { 
      try 
      { 
       XmlDocument profile = DataHelper.GetProfile(userName); 
       UpdateMember(profile); 
      } 
      catch (Exception exception) 
      { 
       if (_log.IsErrorEnabled) _log.ErrorFormat(exception.Message); 
       throw (exception); 
      } 
     }; 

     GetUsers().ForEach(action); 
} 

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

+1

Этот код может находиться за правой дверью: http://www.osnews.com/story/19266/WTFs_m Если вам подходит функциональное программирование, рассмотрите F # вместо этого. –

+0

Спасибо за ваш ответ (и отличную ссылку). Да! Я согласен с тем, что есть WTF, когда вы впервые видите что-то закодированное таким образом. Но, как и в случае чего-либо нового, всегда есть момент WTF, пока вы не потратите время, чтобы посмотреть на него и понять его. После этого вы узнаете образец в будущем и больше не WTF. Если нет ничего плохого в этом способе кодирования (например, производительности); можно ли это просто считать «стилем» кодирования. –

+0

Возможный дубликат [C#, Action/Func vs Methods, в чем смысл?] (Http://stackoverflow.com/questions/7630538/c-action-func-vs-methods-whats-the-point) – nawfal

ответ

4

Для простой петли foreach, я бы предпочел нормальную конструкцию языка - см. this blog post for Eric Lippert's view. Я думаю, что использование делегата здесь несколько безвозмездно.

В других случаях - особенно в LINQ - это имеет большой смысл.

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

+0

Спасибо за ваш ответ и ссылка. Я полагаю, что с LINQ вы имеете в виду, потому что у вас может быть число или утверждения (фильтры и т. Д.), Чтобы сформировать данные, содержащиеся в списке, - которые затем будут работать. Это отличается тем, что просто выполняет некоторые процедурные вызовы методов, как в примере в моем вопросе. –

+0

@Grant: Я имею в виду, что LINQ использует делегаты (или деревья выражений) повсюду. Нет смысла писать логику фильтрации Where, логику проектирования Select и т. Д. Повсюду - тогда как в случае ForEach против foreach вы ничего не получаете, используя делегат. –

+0

Получил это. Спасибо, Джон. –

Смежные вопросы