Should functions that take functions as parameters, also take parameters to those functions as parameters?

Question

I often find myself writing functions that look like this because they allow me to easily mock data access, and still provide a signature that accepts parameters to determine what data to access.

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

Or

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

Then I use it something like this:

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

Is this a common practice? I feel like I should be doing something more like

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

But that doesn't seem to work very well because I'd have to make a new function to pass into the method for every rate type.

Sometimes I feel like I should be doing

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

But that seems to take away any fetch and format re-usability. Whenever I want to fetch and format I have to write two lines, one to fetch and one to format.

What am I missing about functional programming? Is this the right way to do it, or is there a better pattern that's both easy to maintain and use?

Answer 1

If you do this long enough, you'll eventually find yourself writing this function over and over:

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

Congratulations, you've invented function composition.

Wrapper functions like this don't have much use when they're specialized to one type. However, if you introduce some type variables and omit the input parameter, then your GetFormattedRate definition looks like this:

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

As it stands, what you're doing has little purpose. It's not generic, so you need to duplicate that code all over the place. It overcomplicates your code because now your code has to assemble everything it needs from a thousand tiny functions on its own. Your heart's in the right place though: you just need to get used to using these sorts of generic higher order functions to put things together. Or, use a good old fashion lambda to turn Func<A, B> and A into Func<B>.

Don't repeat yourself.

Answer 2

There is absolutely no reason to pass a function, and its parameters, only to then call it with those parameters. In fact, in your case you have no reason to pass a function at all. The caller might as well just call the function itself and pass the result.

Think about it - instead of using:

var formattedRate = GetFormattedRate(getRate, rateType);

why not simply use:

var formattedRate = GetFormattedRate(getRate(rateType));

?

As well as reducing unnecessary code it also reduces coupling - if you want to change how the rate is fetched (say, if getRate now needs two arguments) you don't have to change GetFormattedRate.

Likewise, there's no reason to write GetFormattedRate(formatRate, getRate, rateKey) instead of writing formatRate(getRate(rateKey)).

Don't overcomplicate things.

Answer 3

If you absolutely need to pass a function into the function because it passes some extra argument or calls it in a loop then you can instead pass a lambda:

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

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

The lambda will bind the arguments the function doesn't know about and hide that they even exist.

Answer 4

Isn't this what you want?

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

And then call it like this:

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

        System.PrintLn(formattedRate);
    }
}

If you want a method that can behave in multiple different ways in an object-oriented language such as C#, the usual way to do that is to have the method call an abstract method. If you don't have a specific reason to do it a different way, you should do it that way.

Does this look like a good solution, or are there downsides you're thinking of?