Это неправильно использовать логический параметр для определения значений?

Согласно Неправильно ли использовать логический параметр для определения поведения? Я знаю важность избегания использования логических параметров для определения поведения, например:

оригинальная версия

public void setState(boolean flag){
    if(flag){
        a();
    }else{
        b();
    }
    c();
}

новая версия:

public void setStateTrue(){
    a();
    c();
}

public void setStateFalse(){
    b();
    c();
}

Но как насчет случая, когда логический параметр используется для определения значений вместо поведения? например:

public void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

Я пытаюсь устранить флаг isHintOn и создать 2 отдельные функции:

public void setHintOn(){
    this.layer1.visible=true;
    this.layer2.visible=false;
    this.layer3.visible=true;
}

public void setHintOff(){
    this.layer1.visible=false;
    this.layer2.visible=true;
    this.layer3.visible=false;
}

но модифицированная версия кажется менее ремонтопригодной, потому что:

1. в нем больше кодов, чем в оригинальной версии

2. это не может ясно показать, что видимость layer2 противоположна опции подсказки

3. когда новый слой (например: layer4) добавлен, мне нужно добавить

   this.layer4.visible=false;
   

   а также

   this.layer4.visible=true;  
   

   в setHintOn () и setHintOff () отдельно

Поэтому у меня вопрос: если булев параметр используется только для определения значений, но не для поведения (например, нет в этом параметре if-else), рекомендуется ли по-прежнему исключать этот булев параметр?

Разработка API должна быть сосредоточена на том, что наиболее полезно для клиента API, с вызывающей стороны .

Например, если этот новый API требует от вызывающего абонента регулярно писать такой код

if(flag)
    foo.setStateTrue();
else
    foo.setStateFalse();

тогда должно быть очевидно, что избегать параметра хуже, чем иметь API, который позволяет вызывающей стороне писать

 foo.setState(flag);

Предыдущая версия просто создает проблему, которая затем должна быть решена на вызывающей стороне (и, возможно, более одного раза). Это не увеличивает удобочитаемость и удобство обслуживания.

Сторона реализации , однако, не должна диктовать , как публичный API выглядит. Если функция, подобная setHintпараметру, требует меньше кода при реализации, но API в терминах setHintOn/ setHintOffвыглядит проще для клиента, можно реализовать это следующим образом:

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

Таким образом, хотя публичный API не имеет логического параметра, здесь нет дублирующейся логики, поэтому можно изменить только одно место при появлении нового требования (как в примере с вопросом).

Это работает и наоборот: если setStateвышеуказанному методу нужно переключаться между двумя разными частями кода, эти части кода могут быть реорганизованы в два разных закрытых метода. Поэтому ИМХО не имеет смысла искать критерий для выбора между «один параметр / один метод» и «нулевые параметры / два метода», просматривая внутренние компоненты. Однако посмотрите, как бы вы хотели видеть API в роли его потребителя.

Если вы сомневаетесь, попробуйте использовать «разработку через тестирование» (TDD), которая заставит вас задуматься об общедоступном API и о том, как его использовать.

Мартин Фаулер цитирует Кента Бека, который рекомендует отдельные setOn() setOff()методы , но также говорит, что это не следует считать неприкосновенным:

Если вы потянув [так] данные из булева источника, например, управления пользовательского интерфейса или источника данных, я бы предпочел , setSwitch(aValue)чем

if (aValue)
  setOn();
else
  setOff();

Это пример того, как должен быть написан API, чтобы облегчить его для вызывающего, поэтому, если мы знаем, откуда поступает вызывающий, мы должны разработать API с учетом этой информации. Это также утверждает, что мы можем иногда предоставлять оба стиля, если мы получаем вызывающих абонентов в обоих направлениях.

Другая рекомендация состоит в том, чтобы использовать перечисляемое значение или тип флагов, чтобы дать trueи falseболее точные, зависящие от контекста имена. В твоем примере showHintи hideHintмогло быть и лучше.

Я думаю, что вы смешиваете две вещи в своем посте: API и реализацию. В обоих случаях я не думаю, что есть строгое правило, которое вы можете использовать постоянно, но вы должны рассмотреть эти две вещи независимо (насколько это возможно).

Давайте начнем с API, оба:

public void setHint(boolean isHintOn)

а также:

public void setHintOn()
public void setHintOff()

являются допустимыми альтернативами в зависимости от того, что ваш объект должен предложить и как ваши клиенты будут использовать API. Как отметил Док, если у ваших пользователей уже есть логическая переменная (из элемента управления пользовательского интерфейса, действия пользователя, внешнего интерфейса, API и т. Д.), Первый вариант имеет больше смысла, в противном случае вы просто добавляете дополнительный оператор if в коде клиента. , Однако, если, например, вы меняете подсказку на true при запуске процесса и на false в конце, первый вариант дает вам что-то вроде этого:

setHint(true)
// Do your process
…
setHint(false)

в то время как второй вариант дает вам это:

setHintOn()
// Do your process
…
setHintOff()

какая ИМО гораздо более читабельна, поэтому я перейду ко второму варианту в этом случае. Очевидно, что ничто не мешает вам предлагать оба варианта (или даже больше, вы можете использовать перечисление, как сказал Грэм, если это имеет смысл, например).

Дело в том, что вы должны выбирать свой API, основываясь на том, что должен делать объект и как клиенты будут его использовать, а не на том, как вы собираетесь его реализовать.

Затем вы должны выбрать способ реализации вашего публичного API. Допустим, мы выбрали методы setHintOnи setHintOffнаш публичный API, и они используют эту общую логику, как в вашем примере. Вы можете легко абстрагировать эту логику с помощью частного метода (код, скопированный из Doc):

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

И наоборот, допустим, что мы выбрали setHint(boolean isHintOn)наш API, но давайте перевернем ваш пример, по любой причине установка подсказки On полностью отличается от установки его в Off. В этом случае мы могли бы реализовать это следующим образом:

public void setHint(boolean isHintOn){
    if(isHintOn){
        // Set it On
    } else {
        // Set it Off
    }    
}

Или даже:

public void setHint(boolean isHintOn){    
    if(isHintOn){
        setHintOn()
    } else {
        setHintOff()
   }    
}

private void setHintOn(){
   // Set it On
}

private void setHintOff(){
   // Set it Off 
}

Дело в том, что в обоих случаях мы сначала выбрали наш общедоступный API, а затем адаптировали нашу реализацию для соответствия выбранному API (и имеющимся у нас ограничениям), а не наоборот.

Между прочим, я думаю, что то же самое относится и к сообщению, которое вы связали с использованием логического параметра для определения поведения, то есть вы должны решить, основываясь на вашем конкретном случае использования, а не на каком-то жестком правиле (хотя в этом конкретном случае обычно правильные действия это разбить его на несколько функций).

Перво-наперво: код не менее автоматически обслуживаем, просто потому, что он немного длиннее. Ясность - вот что имеет значение.

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

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

^{(Я позволил себе дать реальным названиям слоев - если у вас нет этого в исходном коде, я бы начал с этого)}

Это все еще оставляет вас с вопросом о том, иметь ли setHintVisibility(bool)метод. Лично я бы рекомендовал заменить его с showHint()и hideHint()методом - как будет на самом деле просто и вам не придется менять их , когда вы добавляете слои. Однако, это не однозначно правильно / неправильно.

Теперь, если вызов функции на самом деле должен изменить видимость этих слоев, у вас действительно есть поведение. В этом случае я бы определенно рекомендовал отдельные методы.

Булевы параметры хороши во втором примере. Как вы уже поняли, логические параметры сами по себе не являются проблематичными. Это переключение поведения на основе флага, что проблематично.

Первый пример, тем не менее, проблематичен, потому что наименование указывает метод установки, но реализации кажутся чем-то другим. Таким образом, у вас есть антипаттерн с переключением поведения и обманчиво названный метод. Но если метод на самом деле является обычным установщиком (без переключения поведения), то с этим проблем нет setState(boolean). Наличие двух методов, setStateTrue()и setStateFalse()это просто без необходимости усложнять вещи без пользы.

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

Например, в Java вы можете сделать:

public enum HintState {
    SHOW_HINT(true, false, true),
    HIDE_HINT(false, true, false);

    private HintState(boolean layer1Visible, boolean layer2Visible, boolean layer3Visible) {
         // constructor body and accessors omitted for clarity
    }
}

И тогда ваш код вызывающего абонента будет выглядеть так:

setHint(HintState.SHOW_HINT);

И ваш код реализации будет выглядеть так:

public void setHint(HintState hint) {
    this.layer1Visible = hint.isLayer1Visible();
    this.layer2Visible = hint.isLayer2Visible();
    this.layer3Visible = hint.isLayer3Visible();
}

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

Поэтому у меня вопрос: если булев параметр используется только для определения значений, но не для поведения (например, нет в этом параметре if-else), рекомендуется ли по-прежнему исключать этот булев параметр?

Когда у меня есть сомнения по поводу таких вещей. Мне нравится представлять, как будет выглядеть трассировка стека.

В течение многих лет я работал над проектом PHP, который использовал ту же функцию, что и setter и getter . Если вы передали значение null, оно вернет значение, в противном случае установите его. С ним было ужасно работать .

Вот пример трассировки стека:

function visible() : line 440
function parent() : line 398
function mode() : line 384
function run() : line 5

Вы понятия не имели о внутреннем состоянии, и это усложняло отладку. Существует множество других негативных побочных эффектов, но постарайтесь увидеть, что в подробном названии функции есть значение и ясность, когда функции выполняют одно действие.

Теперь представьте, как работает трассировка стека для функции, которая имеет поведение A или B на основе логического значения.

function bar() : line 92
function setVisible() : line 120
function foo() : line 492
function setVisible() : line 120
function run() : line 5

Это сбивает с толку, если вы спросите меня. Одни и те же setVisibleлинии дают два разных пути трассировки.

Итак, вернемся к вашему вопросу. Попробуйте представить, как будет выглядеть трассировка стека, как она сообщает человеку, что происходит, и спросите себя, помогаете ли вы будущему человеку отладить код.

Вот несколько советов:

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

Иногда код выглядит чрезмерно под микроскопом, но когда вы возвращаетесь к более широкой картине, минималистичный подход заставит его исчезнуть. Если вам нужно, чтобы он выделялся, чтобы вы могли поддерживать его. Добавление многих небольших функций может показаться слишком многословным, но это улучшает удобство обслуживания при широком использовании в более широком контексте.

Почти в каждом случае, когда вы передаете booleanпараметр методу в качестве флага для изменения поведения чего-либо, вы должны рассмотреть более явный и безопасный для этого способ.

Если вы делаете не что иное, как использование состояния Enum, представляющего состояние, вы улучшили понимание своего кода.

В этом примере используется Nodeкласс из JavaFX:

public enum Visiblity
{
    SHOW, HIDE

    public boolean toggleVisibility(@Nonnull final Node node) {
        node.setVisible(!node.isVisible());
    }
}

всегда лучше, чем, как найдено на многих JavaFXобъектах:

public void setVisiblity(final boolean flag);

но я думаю , .setVisible()и .setHidden()являются лучшим решением для ситуации , когда флаг являетсяboolean поскольку он является наиболее явным и наименее многословным.

в случае чего-то с множественным выбором это еще более важно сделать таким образом. EnumSetсуществует только по этой причине.

Эд Манн имеет действительно хороший пост в блоге только на эту тему. Я собирался перефразировать только то, что он говорит, поэтому, чтобы не дублировать усилия, я просто опубликую ссылку на его блог в качестве приложения к этому ответу.

При выборе между подходом для некоторого интерфейса, который передает (логический) параметр, и перегруженными методами без указанного параметра, обратите внимание на потребляющих клиентов.

Если все виды использования будут передавать постоянные значения (например, истина, ложь), то это приводит к перегрузкам.

Если все случаи использования передают значение переменной, то это аргумент для метода с параметрическим подходом.

Если ни одна из этих крайностей не применима, это означает, что существует разнородное использование клиентов, поэтому вам нужно выбрать, поддерживать ли обе формы, или настроить одну категорию клиентов для адаптации к другой (что для них более неестественный) стиль.

Есть два соображения для проектирования:

• API: какой интерфейс вы представляете пользователю,
• Реализация: ясность, ремонтопригодность и т.д ...

Их не следует смешивать.

Это прекрасно, чтобы:

• иметь несколько методов в делегате API для одной реализации,
• иметь один метод в диспетчеризации API для нескольких реализаций в зависимости от условия.

Таким образом, любой аргумент, который пытается сбалансировать затраты / выгоды дизайна API с затратами / преимуществами проекта реализации, является сомнительным и должен быть тщательно изучен.

На стороне API

Как программист, я обычно предпочитаю программируемые API. Код гораздо понятнее, когда я могу переслать значение, чем когда мне нужно выражение if/ switchдля значения, чтобы решить, какую функцию вызывать.

Последнее может быть необходимо, если каждая функция ожидает разные аргументы.

В вашем случае, таким образом, единственный метод setState(type value) кажется лучше.

Тем не менее , нет ничего хуже, чем безымянные true, falseи 2т. Д. ... эти магические ценности не имеют значения сами по себе. Избегайте примитивных навязчивых идей и придерживайтесь строгой типизации.

Таким образом, с API POV, я хочу: setState(State state).

На стороне реализации

Я рекомендую делать все, что проще.

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

Наконец, рассмотрим группировку .

В вашем примере (с добавленными пробелами для удобства чтения):

this.layer1.visible = isHintOn;
this.layer2.visible = ! isHintOn;
this.layer3.visible = isHintOn;

Почему layer2противодействует тенденция? Это особенность или это ошибка?

Возможно ли иметь 2 списка [layer1, layer3]и [layer2], с явным именем, указывающим причину, по которой они сгруппированы, а затем выполнить итерацию по этим спискам.

Например:

for (auto layer : this.mainLayers) { // layer2
    layer.visible = ! isHintOn;
}
for (auto layer : this.hintLayers) { // layer1 and layer3
    layer.visible = isHintOn;
}

Кодекс говорит сам за себя, понятно, почему есть две группы, и их поведение отличается.

Отдельно от вопроса setOn() + setOff()против set(flag), я бы тщательно подумал, лучше ли здесь использовать логический тип. Вы уверены, что никогда не будет третьего варианта?

Возможно, стоит рассмотреть перечисление вместо логического. Помимо возможности расширения, это также затрудняет неправильное получение логического значения, например:

setHint(false)

против

setHint(Visibility::HIDE)

С помощью enum будет намного легче расширяться, когда кто-то решит, что он хочет использовать опцию «при необходимости»:

enum class Visibility {
  SHOW,
  HIDE,
  IF_NEEDED // New
}

против

setHint(false)
setHint(true)
setHintAutomaticMode(true) // New

Согласно ..., я знаю важность избегания использования логических параметров для определения поведения

Я бы предложил переоценить эти знания.

Прежде всего, я не вижу вывод, который вы предлагаете в вопросе SE, который вы связали. В основном они говорят о переадресации параметра на несколько этапов вызовов метода, где он оценивается очень далеко по цепочке.

В вашем примере вы оцениваете параметр прямо в вашем методе. В этом отношении он ничем не отличается от других параметров.

В общем, нет ничего плохого в использовании логических параметров; и, очевидно, какой-либо параметр будет определять поведение, или с чего бы вам это вообще понадобилось?

Определение вопроса

Ваш титульный вопрос: "Это неправильно [...]?" - но что вы имеете в виду под «неправильно»?

Согласно компилятору C # или Java, это не так. Я уверен, что вы знаете об этом, и это не то, что вы спрашиваете. Боюсь, кроме этого, у нас только nпрограммисты n+1разные мнения. Этот ответ представляет то, что книга Чистый Кодекс говорит об этом.

Ответ

Чистый код делает веские аргументы против аргументов функции в целом:

Аргументы жесткие. Они берут много концептуальной силы. [...] наши читатели должны были бы интерпретировать это каждый раз, когда они видели это.

«Читатель» здесь может быть потребителем API. Это также может быть следующий кодировщик, который еще не знает, что делает этот код, - которым вы могли бы стать через месяц. Они будут либо проходить через 2 функции отдельно, либо через 1 функцию дважды , один раз помня trueи один раз falseпомня.
Короче говоря, используйте как можно меньше аргументов .

Конкретный случай аргумента флага позже рассматривается напрямую:

Аргументы флагов ужасны. Передача логического выражения в функцию - это действительно ужасная практика. Это сразу усложняет сигнатуру метода, громко заявляя, что эта функция делает больше, чем одно. Он делает одно, если флаг имеет значение true, и другое, если флаг имеет значение false!

Чтобы ответить на ваши вопросы напрямую: в
соответствии с «Чистым кодом» рекомендуется исключить этот параметр.

Дополнительная информация:

Ваш пример довольно прост, но даже там вы можете увидеть простоту, распространяющуюся на ваш код: функции без параметров выполняют только простые присваивания, в то время как другая функция должна выполнять булеву арифметику для достижения той же цели. В этом упрощенном примере это тривиальная логическая арифметика, но она может быть довольно сложной в реальной ситуации.

Я видел много аргументов, что вы должны сделать это зависимым от пользователя API, потому что делать это во многих местах было бы глупо:

if (isAfterSunset) light.TurnOn();
else light.TurnOff();

Я действительно согласен , что - то неоптимальным, что здесь происходит. Может быть, это слишком очевидно, чтобы увидеть, но ваше самое первое предложение упоминает «важность избегать [sic] использования булевых параметров для определения поведения», и это является основой для всего вопроса. Я не вижу причины, чтобы сделать эту вещь, которую плохо делать проще для пользователя API.

Я не знаю, проводите ли вы тестирование - в этом случае также подумайте об этом:

Аргументы еще сложнее с точки зрения тестирования. Представьте себе трудность написания всех тестовых случаев, чтобы гарантировать, что все различные комбинации аргументов работают правильно. Если нет аргументов, это тривиально.