Le funzioni che prendono le funzioni come parametri, devono prendere anche i parametri di quelle funzioni come parametri?

Mi ritrovo spesso a scrivere funzioni simili a queste perché mi consentono di deridere facilmente l'accesso ai dati e forniscono comunque una firma che accetta i parametri per determinare a quali dati accedere.

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

O

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

Quindi lo uso in questo modo:

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);
}

È una pratica comune? Sento che dovrei fare qualcosa di più simile

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

Ma questo non sembra funzionare molto bene perché dovrei creare una nuova funzione per passare al metodo per ogni tipo di tariffa.

A volte mi sento come se dovessi farlo

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

Ma questo sembra togliere qualsiasi riutilizzo e formattazione. Ogni volta che voglio recuperare e formattare devo scrivere due righe, una per recuperare e una per formattare.

Cosa mi manca della programmazione funzionale? È questo il modo giusto di farlo o esiste un modello migliore che sia facile da mantenere e da usare?

Se lo fai abbastanza a lungo, alla fine ti ritroverai a scrivere questa funzione ancora e ancora:

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

Complimenti, hai inventato la composizione delle funzioni .

Le funzioni wrapper come questa non sono molto utili quando sono specializzate in un tipo. Tuttavia, se si introducono alcune variabili di tipo e si omette il parametro di input, la definizione GetFormattedRate è simile alla seguente:

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);

Così com'è, quello che stai facendo ha poco scopo. Non è generico, quindi è necessario duplicare quel codice ovunque. Complica in modo eccessivo il tuo codice perché ora il tuo codice deve assemblare tutto ciò di cui ha bisogno da mille minuscole funzioni da solo. Il tuo cuore è nel posto giusto: devi solo abituarti a usare questo tipo di funzioni generiche di ordine superiore per mettere insieme le cose. Oppure, usa un buon vecchio stile lambda per trasformarti Func<A, B>e trasformarlo AinFunc<B> .

Non ripeterti.

Non c'è assolutamente alcun motivo per passare una funzione e i suoi parametri, solo per poi chiamarla con quei parametri. In effetti, nel tuo caso non hai motivo di passare una funzione a tutti . Il chiamante potrebbe anche semplicemente chiamare la funzione stessa e passare il risultato.

Pensaci - invece di usare:

var formattedRate = GetFormattedRate(getRate, rateType);

perché non usare semplicemente:

var formattedRate = GetFormattedRate(getRate(rateType));

?

Oltre a ridurre il codice non necessario, riduce anche l'accoppiamento: se si desidera modificare il modo in cui viene recuperata la frequenza (ad esempio, se getRateora sono necessari due argomenti) non è necessario modificareGetFormattedRate .

Allo stesso modo, non c'è motivo di scrivere GetFormattedRate(formatRate, getRate, rateKey)invece di scrivere formatRate(getRate(rateKey)).

Non complicare eccessivamente le cose.

Se hai assolutamente bisogno di passare una funzione nella funzione perché passa qualche argomento in più o la chiama in un ciclo, puoi invece passare un lambda:

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

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

La lambda rileverà gli argomenti di cui la funzione non è a conoscenza e nasconderà che esistono persino.

Non è questo quello che vuoi?

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;
    }
}

E poi chiamalo così:

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

        System.PrintLn(formattedRate);
    }
}

Se si desidera un metodo che può comportarsi in diversi modi in un linguaggio orientato agli oggetti come C #, il modo normale per farlo è quello di fare in modo che il metodo chiami un metodo astratto. Se non hai un motivo specifico per farlo in modo diverso, dovresti farlo in questo modo.

Sembra una buona soluzione o ci sono degli aspetti negativi a cui stai pensando?