Локальная функция против Lambda C # 7.0

Я смотрю на новые реализации в C # 7.0, и мне интересно, что они реализовали локальные функции, но я не могу представить сценарий, где локальная функция предпочтительнее лямбда-выражения, и в чем разница между ними.

Я понимаю, что лямбда- anonymousфункции являются функциями, в то время как локальные функции - нет, но я не могу понять сценарий реального мира, где локальная функция имеет преимущества перед лямбда-выражениями

Любой пример будет высоко ценится. Спасибо.

Это было объяснено Мэдсом Торгерсеном из C # Design Notes, где впервые обсуждались локальные функции :

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

Чтобы расширить это еще, преимущества:

1. Производительность.

   При создании лямбды должен быть создан делегат, который в данном случае является ненужным. Локальные функции - это просто функции, делегаты не нужны.

   Кроме того, локальные функции более эффективны при захвате локальных переменных: лямбда-выражения обычно записывают переменные в класс, в то время как локальные функции могут использовать структуру (передается с использованием ref), что опять-таки позволяет избежать выделения.

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

2. Локальные функции могут быть рекурсивными.

   Лямбды также могут быть рекурсивными, но для этого требуется неудобный код, в котором вы сначала назначаете nullпеременную-делегат, а затем лямбду. Локальные функции могут быть рекурсивными (в том числе взаимно рекурсивными).

3. Локальные функции могут быть общими.

   Лямбды не могут быть универсальными, поскольку они должны быть назначены переменной с конкретным типом (этот тип может использовать универсальные переменные из внешней области видимости, но это не одно и то же).

4. Локальные функции могут быть реализованы как итератор.

   Lambdas не может использовать ключевое слово yield return(и yield break) для реализации IEnumerable<T>функции -returning. Локальные функции могут.

5. Локальные функции выглядят лучше.

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

   Для сравнения:

   int add(int x, int y) => x + y;
   Func<int, int, int> add = (x, y) => x + y;

В дополнение к хорошему ответу svick, есть еще одно преимущество для локальных функций:
они могут быть определены в любом месте функции, даже после returnоператора.

public double DoMath(double a, double b)
{
    var resultA = f(a);
    var resultB = f(b);
    return resultA + resultB;

    double f(double x) => 5 * x + 3;
}

Если вы также задаетесь вопросом, как проверить локальную функцию, вам следует проверить JustMock, поскольку она имеет функциональные возможности для этого. Вот простой пример класса, который будет протестирован:

public class Foo // the class under test
{ 
    public int GetResult() 
    { 
        return 100 + GetLocal(); 
        int GetLocal () 
        { 
            return 42; 
        } 
    } 
}

А вот как выглядит тест:

[TestClass] 
public class MockLocalFunctions 
{ 
    [TestMethod] 
    public void BasicUsage() 
    { 
        //Arrange 
        var foo = Mock.Create<Foo>(Behavior.CallOriginal); 
        Mock.Local.Function.Arrange<int>(foo, "GetResult", "GetLocal").DoNothing(); 

        //Act 
        var result = foo. GetResult(); 

        //Assert 
        Assert.AreEqual(100, result); 
    } 
} 

Вот ссылка на документацию JustMock .

Отказ от ответственности. Я один из разработчиков, отвечающих за JustMock .

Я использую встроенные функции, чтобы избежать давления при сборке мусора, особенно при работе с более длительными методами. Допустим, вы хотите получить 2 года или рыночные данные для данного символа тикера. Кроме того, можно упаковать много функциональности и бизнес-логики, если это необходимо.

все, что нужно сделать - это открыть сокетное соединение с сервером и зациклить данные, привязывающие событие к событию. Можно думать об этом так же, как проектируется класс, только один не пишет повсеместно вспомогательные методы, которые действительно работают только для одной функциональности. ниже приведен пример того, как это может выглядеть, обратите внимание, что я использую переменные, а методы "helper" находятся ниже, наконец. Наконец, я удаляю обработчики событий, если мой класс Exchange будет внешним / внедренным, у меня не будет зарегистрирован ни один ожидающий обработчик событий.

void List<HistoricalData> RequestData(Ticker ticker, TimeSpan timeout)
{
    var socket= new Exchange(ticker);
    bool done=false;
    socket.OnData += _onData;
    socket.OnDone += _onDone;
    var request= NextRequestNr();
    var result = new List<HistoricalData>();
    var start= DateTime.Now;
    socket.RequestHistoricalData(requestId:request:days:1);
    try
    {
      while(!done)
      {   //stop when take to long….
        if((DateTime.Now-start)>timeout)
           break;
      }
      return result;

    }finally
    {
        socket.OnData-=_onData;
        socket.OnDone-= _onDone;
    }


   void _OnData(object sender, HistoricalData data)
   {
       _result.Add(data);
   }
   void _onDone(object sender, EndEventArgs args)
   {
      if(args.ReqId==request )
         done=true;
   } 
}

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