¿Deberían las funciones que toman funciones como parámetros, también llevar parámetros a esas funciones como parámetros?

A menudo me encuentro escribiendo funciones que se ven así porque me permiten burlarme fácilmente del acceso a los datos y aún así proporcionar una firma que acepta parámetros para determinar a qué datos acceder.

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

Entonces lo uso algo como esto:

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

¿Es esta una práctica común? Siento que debería estar haciendo algo más como

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

Pero eso no parece funcionar muy bien porque tendría que hacer una nueva función para pasar al método para cada tipo de tasa.

A veces siento que debería estar haciendo

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

Pero eso parece eliminar cualquier reutilización de búsqueda y formato. Cada vez que quiero buscar y formatear tengo que escribir dos líneas, una para buscar y otra para formatear.

¿Qué me falta de programación funcional? ¿Es esta la forma correcta de hacerlo, o hay un patrón mejor que sea fácil de mantener y usar?

Si hace esto lo suficiente, eventualmente se encontrará escribiendo esta función una y otra vez:

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

Felicidades, has inventado la composición de funciones .

Las funciones de envoltura como esta no tienen mucho uso cuando están especializadas en un tipo. Sin embargo, si introduce algunas variables de tipo y omite el parámetro de entrada, su definición de GetFormattedRate se verá así:

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

Tal como está, lo que estás haciendo tiene poco propósito. No es genérico, por lo que debe duplicar ese código por todas partes. Sobrecomplica su código porque ahora su código tiene que ensamblar todo lo que necesita de mil funciones pequeñas por sí solo. Sin embargo, su corazón está en el lugar correcto: solo necesita acostumbrarse a usar este tipo de funciones genéricas de orden superior para armar las cosas. O bien, utilizar una buena lambda vieja manera de convertir Func<A, B>y Aen Func<B>.

No te repitas a ti mismo.

No hay absolutamente ninguna razón para pasar una función y sus parámetros, solo para luego llamarla con esos parámetros. De hecho, en su caso no tiene ninguna razón para pasar una función en absoluto . La persona que llama también podría llamar a la función en sí y pasar el resultado.

Piénselo, en lugar de usar:

var formattedRate = GetFormattedRate(getRate, rateType);

por qué no simplemente usar:

var formattedRate = GetFormattedRate(getRate(rateType));

?

Además de reducir el código innecesario, también reduce el acoplamiento: si desea cambiar la forma en que se obtiene la velocidad (por ejemplo, si getRateahora necesita dos argumentos), no tiene que cambiar GetFormattedRate.

Del mismo modo, no hay razón para escribir en GetFormattedRate(formatRate, getRate, rateKey)lugar de escribir formatRate(getRate(rateKey)).

No compliques demasiado las cosas.

Si absolutamente necesita pasar una función a la función porque pasa algún argumento adicional o la llama en un bucle, entonces puede pasar una 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 vinculará los argumentos que la función no conoce y ocultará que incluso existen.

¿No es esto lo que quieres?

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

Y luego llámalo así:

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

        System.PrintLn(formattedRate);
    }
}

Si desea un método que pueda comportarse de múltiples maneras diferentes en un lenguaje orientado a objetos como C #, la forma habitual de hacerlo es hacer que el método llame a un método abstracto. Si no tiene una razón específica para hacerlo de una manera diferente, debe hacerlo de esa manera.

¿Esto parece una buena solución, o hay inconvenientes en los que estás pensando?