C# lambda, przypisz lokalną zmienną do danych zwrotnych

Question

W języku C#, lambda może uzyskać dostęp do zmiennej lokalnej, a także zwrócić niektóre dane.

, co jest lepsze w tej sytuacji?

int num; 
Func<int> func =()=>{return 10;} 
num = func(); 

vs

int num; 
Action action =()=>{num = 10;} 

myślę, wydajność jest różna. Co jest lepsze?



AKTUALIZACJA (nie wiem jak używać StackOverflow)

mój kod tutaj.

ErrorCode errorCode; 
errorCode = DatabaseUtility.Read<ErrorCode>(
    conn, 
    DatabaseUtility.CreateSelectQuery(....), 
    reader => 
    { 
     if(reader.Read()) 
      return ErrorCode.None; 

     return ErrorCode.InvalidParam; 
    }); 

Ale w takim przypadku mogę być w stanie to zrobić.

ErrorCode errorCode; 
DatabaseUtility.Read(
    conn, 
    DatabaseUtility.CreateSelectQuery(....), 
    reader => 
    { 
     if(reader.Read()) 
      errorCode = ErrorCode.None; 
     else 
      errorCode = ErrorCode.InvalidParam; 
    }); 

I to jest definicja metody.

public static class DatabaseUtility 
{ 
    public static Read<T>(
     MySqlConnection conn, 
     string query, 
     Func<MySqlDataReader, T> callback); 
} 

Answer 1

Pierwszy z nich jest lepiej zaprojektowany. Jest on wielokrotnego użytku i może być wywoływany wielokrotnie na różnych zmiennych (jeśli jest to wymagane).

Osiągi, których nie jestem pewien, najprawdopodobniej nieistotne.

Answer 2

Gibbo ma rację: zwracanie wartości jest bardziej wyraźne, więc powinieneś tego użyć i nie martwić się wydajnością, chyba że ten kod jest w the 3% of code when microoptimizations make sense.

Ale zwracanie może być również bardziej efektywne, ponieważ nie wymaga przydziału sterty dla obiektu zamknięcia, a ponieważ oznacza to, że num zostanie skompilowany jako zmienna lokalna, a nie pole obiektu zamknięcia (dostęp do lokalnego zmienne są tańsze niż pola).

Ponadto, jeśli masz zamiar zwrócić wartość, nie ma powodu, aby zadeklarować zmienną tak wcześnie, co uczyni Twój kod nieznacznie krótsza:

Func<int> func =()=>{return 10;} 
int num = func(); 

Answer 3

Właściwie istnieje duża różnica semantyczne.

() => 10; 
() => x = 10; 

Zarówno powrócić 10. Różnica polega na tym, że w drugim przypadku zmienna x zostaje schwytany, związany z ciałem Lamba i mogą podróżować przez kontekstach.

Imagine:

void SomeFunction() 
{ 
    int variable; 
    Execute((a) => variable = a); 
} 

void Execute(Action<int> statement) 
{ 
    statement.Invoke(7); 
} 

Tutaj SomeFunc nie ma pojęcia, jaka jest wartość zmiennej będzie przy wyjściu z kontekstu funkcji. Z drugiej strony Execute nie ma pojęcia, co stanie się z wartością przekazaną do obiektu funkcji przez Invoke. Może to być przydatne w niektórych kontekstach enkapsulacji. A może w sytuacjach, w których trafisz na limity generyczne C# (co jest bardzo łatwe przy okazji).

Możesz myśleć w obie strony, jeśli chodzi o kod. na przykład"Czy chcę obsłużyć błędy po mojej stronie, czy też udostępnić użytkownikowi mojego interfejsu sposób obsługi błędów?"

Ale wtedy wolałbym użyć klasy abstrakcyjnej do wdrożenia/wymuszenia wyżej wspomnianego zachowania zamiast lambd.

Ogólnie mówiąc, wysyłanie przechwyconych zmiennych w kontekstach wydaje się ukrywać zależności i sprawia, że ​​kod jest trudniejszy (w niektórych przypadkach nawet niemożliwy) do czytania i debugowania. Myślę, że powinno to być używane tylko w scenariuszach, gdzie wszystkie inne środki C# dają bardzo powolny lub bardzo brzydki kod.

Answer 4

Chcę podnieść mały problem z kodem ty Wysłany:

public static class DatabaseUtility 
{ 
    public static Read<T>(
     MySqlConnection conn, 
     string query, 
     Func<MySqlDataReader, T> callback); 
} 

metoda ma podpis typu powrót! czy to jest puste? Jeśli jest nieważny kod zostanie zaksięgowana nie zadziała:

ErrorCode errorCode; 
errorCode = DatabaseUtility.Read<ErrorCode>(
    conn, 
    DatabaseUtility.CreateSelectQuery(....), 
    reader => 
    { 
     if(reader.Read()) 
      return ErrorCode.None; 

     return ErrorCode.InvalidParam; 
    }); 

jeśli jest T już wtedy nie ma potrzeby deklarowania Func aby przejść do funkcji czytania.

Myślę, że w tym przypadku zwracana jest wartość funkcji Read, która powinna być T, i biorąc pod uwagę, że chcesz wykonać działanie z typem danych, który pobierasz (w przypadku jakiegoś błędu lub w innym przypadku), lepiej zdać działania zamiast:

public static class DatabaseUtility 
{ 
    public static T Read<T>(
     MySqlConnection conn, 
     string query, 
     Action<MySqlDataReader> callback); 
} 

założeniu, że Wydajność mądry to nie powinno być problemem, jeśli nie są kierowane do stosowania w czasie rzeczywistym (co moim zdaniem to nie twoja sprawa). Jednak byłoby to lepsze rozwiązanie IMHO.

nadzieję, że to pomaga.