Чи повинні функції, які приймають функції як параметри, також приймати параметри для цих функцій як параметри?

Я часто опиняюсь як пишу функції, які виглядають так, тому що вони дозволяють мені легко знущатися над доступом до даних, і все ще надаю підпис, який приймає параметри, щоб визначити, до яких даних отримувати доступ.

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

Або

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

Тоді я використовую це приблизно так:

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

Це звичайна практика? Я відчуваю, що мені слід робити щось подібне

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

Але це, здається, не дуже добре працює, тому що мені доведеться зробити нову функцію, щоб перейти в метод для кожного типу курсу.

Іноді я відчуваю, що мені належить займатися

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

Але це, здається, забирає будь-яку обробку та повторну зручність використання формату. Щоразу, коли я хочу отримати і форматувати, я повинен написати два рядки, один для отримання та один для форматування.

Що мені не вистачає у функціональному програмуванні? Це правильний спосіб зробити це, чи є кращий зразок, який простий в обслуговуванні та використанні?

Якщо ви будете робити це досить довго, ви, зрештою, знову опиняєтеся писати цю функцію:

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

Вітаємо, ви придумали склад функції .

Такі функції обгортки не мають великого використання, коли вони спеціалізуються на одному типі. Однак якщо ви вводите деякі змінні типу і опускаєте вхідний параметр, то ваше визначення GetFormattedRate виглядає так:

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

Як видно, те, що ви робите, має мало мети. Це не є загальним, тому вам потрібно дублювати цей код всюди. Це надмірно ускладнює ваш код, оскільки тепер ваш код повинен зібрати все, що потрібно, з тисячі крихітних функцій самостійно. Однак ваше серце в потрібному місці: вам просто потрібно звикнути використовувати ці різновиди загальних функцій вищого порядку, щоб зібрати речі. Або використовувати добру стару добру лямбда, щоб перетворити Func<A, B>і Aперетворити її Func<B>.

Не повторюйте себе.

Немає абсолютно ніяких причин передавати функцію та її параметри, лише потім викликати її цими параметрами. Справді, в вашому випадку немає ніяких підстав , щоб передати функцію взагалі . Абонент може просто викликати саму функцію і передавати результат.

Подумайте над цим, а не використовуйте:

var formattedRate = GetFormattedRate(getRate, rateType);

чому б просто не використовувати:

var formattedRate = GetFormattedRate(getRate(rateType));

?

Окрім зменшення непотрібного коду, він також зменшує з'єднання - якщо ви хочете змінити спосіб отримання курсу (скажімо, якщо getRateзараз потрібні два аргументи), вам не потрібно змінювати GetFormattedRate.

Так само немає причини писати GetFormattedRate(formatRate, getRate, rateKey)замість того, щоб писати formatRate(getRate(rateKey)).

Не переплутайте речі.

Якщо вам абсолютно потрібно передати функцію у функцію, оскільки вона передає якийсь додатковий аргумент або викликає її у циклі, тоді ви можете замість цього передати лямбда:

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

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

Лямбда прив’яже аргументи, про які функція не знає, і приховає, що вони навіть існують.

Хіба це не те, що ти хочеш?

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

А потім назвіть це так:

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

        System.PrintLn(formattedRate);
    }
}

Якщо ви хочете, щоб метод, який може вести себе декількома різними способами в об'єктно-орієнтованій мові, такі як C #, звичайний спосіб зробити це, щоб метод викликав абстрактний метод. Якщо у вас немає конкретної причини зробити це по-іншому, ви повинні зробити це так.

Це виглядає як хороше рішення, чи є недоліки, про які ви думаєте?