.NET Разработчик on Telegram: “День 1867. #BestPractices Избегайте Нескольких Б…”

День 1867. #BestPractices
Избегайте Нескольких Булевых Параметров
Булевы параметры хороши, но сложно отследить, что делает каждый из них, если их несколько. Сегодня посмотрим, почему лучше избегать использования нескольких булевых параметров и как это отрефакторить.

Почему это плохо?
Посмотрим на следующий метод:

/// <summary>
/// Refreshes the control.
/// </summary>
/// <param name="force">Forces a refresh even if the renderer is suspended.</param>
/// <param name="lazy">Refreshes the control only if a set amount of time
/// has passed since the last refresh.</param>
void Refresh(bool force, bool lazy);

Это пример из библиотеки компонентов ImageListView. Проблема здесь в том, что два логических параметра обозначают четыре разные комбинации значений:

Refresh(true, true); 
Refresh(true, false);
Refresh(false, true);
Refresh(false, false);

И в некоторой степени вы ожидаете четырёх разных вариантов поведения. Но в реализации это не так:

internal void Refresh(bool force, bool lazy)
{
    if (force)
        base.Refresh();
    else if (lazy)
    {
        rendererNeedsPaint = true;
        lazyRefreshTimer.Start();
    }
    else if (CanPaint())
        base.Refresh();
    else
        rendererNeedsPaint = true;
}

Разрешены только определённые комбинации. Кроме того, «сила» и «ленивость» кажутся в этом контексте противоречивыми. Трудно запомнить, что делает каждая комбинация. Можно сказать, что это в некоторой степени нарушает «принцип единой ответственности», поскольку метод выполняет несколько задач.

Другой частый пример: есть уже существующий метод, и какой-то новый метод должен расширить/изменить его поведение. Для простоты предположим, что нужна сортировка. Самый простой способ — добавить булев параметр:

IEnumerable<Item> GetItems(Filter f);
IEnumerable <Item> GetItems(Filter f, bool sort);
// или ещё хуже:
IEnumerable <Item> GetItems(Filter f, bool sort, bool descending);

Проблема здесь – понять, что происходит. И чем больше параметров, тем больше комбинаций и тем сложнее понять метод.

Рефакторинг
1. Сделать каждую комбинацию отдельным методом
Так все варианты очевидны, и вы можете использовать более выразительное имя метода. Из примера выше:

void Refresh();
void RefreshForce();
void RefreshLazy();

Теперь ясно, что недопустимо использовать оба параметра сразу. При этом мы возлагаем на вызывающую сторону ответственность за решение, какой метод вызывать. Клиент знает, что он хочет сделать, и может выразить это более чётко. Внутри эти методы, безусловно, могут совместно использовать большую часть кода. Кроме того, если нужно изменить поведение одного из методов, это гораздо проще сделать, поскольку между ними меньше связи.

Замечание: надо различать общедоступный API и закрытые методы. Можно иметь несколько булевых параметров в закрытых методах, но надо стараться избегать их в публичных API. Публичный API - интерфейс с внешним миром и должен быть максимально понятным.

2. Использовать перечисления с возможными вариантами

enum RefreshMode { Default, Force, Lazy }

void Refresh(RefreshMode mode);

Хотя здесь показаны все возможные варианты, это не так ясно, как предыдущий подход. Все ещё возможно, что метод делает слишком много. Здесь всегда компромисс между слишком большим количеством параметров и слишком большим количеством методов.

Источник: https://steven-giesel.com/blogPost/9994b00c-8bc2-4794-ae74-80e6ee4cd5e5/avoid-multiple-boolean-parameters