Czy funkcje, które przyjmują funkcje jako parametry, również powinny przyjmować parametry do tych funkcji jako parametry?

Często zdarza mi się pisać funkcje, które wyglądają tak, ponieważ pozwalają mi łatwo kpić z dostępu do danych i nadal dostarczają podpis, który akceptuje parametry określające, do których danych mam dostęp.

public static string GetFormattedRate(
        Func<string, RateType>> getRate,
        string rateKey)
{
    var rate = getRate(rateKey);
    var formattedRate = rate.DollarsPerMonth.ToString("C0");
    return formattedRate;
}

Lub

public static string GetFormattedRate(
        Func<RateType, string> formatRate,
        Func<string, RateType>> getRate,
        string rateKey)
{
    var rate = getRate(rateKey);
    var formattedRate = formatRate(rate);
    return formattedRate;
}

Potem używam czegoś takiego:

using FormatterModule;

public static Main()
{
    var getRate = GetRateFunc(connectionStr);
    var formattedRate = GetFormattedRate(getRate, rateType);
    // or alternatively
    var formattedRate = GetFormattedRate(getRate, FormatterModule.FormatRate, rateKey);

    System.PrintLn(formattedRate);
}

Czy to powszechna praktyka? Czuję, że powinienem robić coś więcej

public static string GetFormattedRate(
        Func<RateType> getRate())
{
    var rate = getRate();
    return rate.DollarsPerMonth.ToString("C0");
}

Ale to nie wydaje się działać zbyt dobrze, ponieważ musiałbym stworzyć nową funkcję, aby przejść do metody dla każdego rodzaju stawki.

Czasami czuję, że powinienem to robić

public static string GetFormattedRate(RateType rate)
{
   return rate.DollarsPerMonth.ToString("C0");
}

Ale wydaje się, że to zabiera ponowne pobieranie i formatowanie. Ilekroć chcę pobrać i sformatować, muszę napisać dwa wiersze, jeden do pobrania, a drugi do sformatowania.

Czego brakuje mi w programowaniu funkcjonalnym? Czy to właściwy sposób, aby to zrobić, czy jest lepszy wzór, który jest jednocześnie łatwy w utrzymaniu i użyciu?

Jeśli zrobisz to wystarczająco długo, w końcu będziesz musiał ciągle pisać tę funkcję:

public static Type3 CombineFunc1AndFunc2(
    Func<Type1, Type2> func1,
    Func<Type2, Type3>> func2,
    Type1 input)
{
    return func2(func1(input))
}

Gratulacje, wymyśliłeś kompozycję funkcji .

Takie funkcje otoki nie mają większego zastosowania, gdy są wyspecjalizowane w jednym typie. Jeśli jednak wprowadzisz niektóre zmienne typu i pominiesz parametr wejściowy, twoja definicja GetFormattedRate wygląda następująco:

public static Func<A, C> Compose(
    Func<B, C> outer, Func<A, B>> inner)
{
    return (input) => outer(inner(input))
}

var GetFormattedRate = Compose(FormatRate, GetRate);
var formattedRate = GetFormattedRate(rateKey);

W tej chwili to, co robisz, ma niewielki cel. Nie jest ogólny, więc musisz powielić ten kod w dowolnym miejscu. Nadmiernie komplikuje twój kod, ponieważ teraz twój kod musi zebrać wszystko, czego potrzebuje, z tysiąca małych funkcji. Twoje serce jest jednak we właściwym miejscu: wystarczy przyzwyczaić się do używania tego rodzaju ogólnych funkcji wyższego rzędu, aby złożyć wszystko w całość. Lub skorzystać z dobrej starej mody lambda, aby włączyć Func<A, B>i Ado Func<B>.

Nie powtarzaj się.

Nie ma absolutnie żadnego powodu, aby przekazywać funkcję i jej parametry, a jedynie wywoływać ją z tymi parametrami. W rzeczywistości, w przypadku, gdy nie ma powodu, aby przekazać funkcję w ogóle . Osoba wywołująca może równie dobrze wywołać samą funkcję i przekazać wynik.

Pomyśl o tym - zamiast używać:

var formattedRate = GetFormattedRate(getRate, rateType);

dlaczego nie użyć po prostu:

var formattedRate = GetFormattedRate(getRate(rateType));

?

Oprócz zmniejszenia niepotrzebnego kodu zmniejsza również sprzężenie - jeśli chcesz zmienić sposób pobierania stawki (powiedz, jeśli getRateteraz potrzebujesz dwóch argumentów), nie musisz zmieniaćGetFormattedRate .

Podobnie nie ma powodu, aby pisać GetFormattedRate(formatRate, getRate, rateKey)zamiast pisać formatRate(getRate(rateKey)).

Nie komplikuj rzeczy.

Jeśli absolutnie potrzebujesz przekazać funkcję do funkcji, ponieważ przekazuje ona dodatkowy argument lub wywołuje ją w pętli, możesz zamiast tego przekazać lambda:

public static string GetFormattedRate(
        Func<string> getRate)
{
    var rate = getRate();
    var formattedRate = rate.DollarsPerMonth.ToString("C0");
    return formattedRate;
}

var formattedRate = GetFormattedRate(()=>getRate(rateKey));

Lambda powiąże argumenty, o których funkcja nie wie, i ukryje, że one nawet istnieją.

Czy nie tego chcesz?

class RateFormatter
{
    public abstract RateType GetRate(string rateKey);

    public abstract string FormatRate(RateType rate);

    public string GetFormattedRate(string rateKey)
    {
        var rate = GetRate(rateKey);
        var formattedRate = FormatRate(rate);
        return formattedRate;
    }
}

A potem nazwij to tak:

static class Program
{
    public static void Main()
    {
        var rateFormatter = new StandardRateFormatter(connectionStr);
        var formattedRate = rateFormatter.GetFormattedRate(rateKey);

        System.PrintLn(formattedRate);
    }
}

Jeśli potrzebujesz metody, która może zachowywać się na wiele różnych sposobów w języku obiektowym, takim jak C #, zwykłym sposobem na to jest wywołanie metody abstrakcyjnej. Jeśli nie masz konkretnego powodu, aby zrobić to inaczej, powinieneś to zrobić w ten sposób.

Czy to wygląda na dobre rozwiązanie, czy może są jakieś wady?