Лучше Show () + Hide () или SetVisible (bool видимый)?

Что лучше и почему? (С точки зрения дизайна интерфейса):

а) иметь два Show()и Hide()функции

б) иметь одну SetVisible(bool visible)функцию

РЕДАКТИРОВАТЬ: Например, некоторые объекты имеют состояние видимости, и эта функция используется для его изменения.

в) иметь все три Show(), Hide(), SetVisible(bool visible)функции

Я предпочитаю SetVisible(bool visible), потому что это позволяет мне писать код клиента так:

SetVisible(DetermineIfItShouldBeVisible());

вместо того, чтобы писать

if (DetermineIfItShouldBeVisible()) {
    Show();
} else {
    Hide();
}

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

void ButtonWithALabel::SetVisible(bool visible) {
    myButton.SetVisible(visible);
    myLabel.SetVisible(visible);
}

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

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

Я думаю, что setVisible()следует отдавать предпочтение по этим причинам:

1. Сразу видно, что такое обратная функция. На обратный setVisible(false)вызов вы звоните, setVisible(true)тогда как противоположность hide()легко может быть reveal().
2. Программно проще всякий раз, когда вы определяете, какое состояние должно быть в коде, т.е. вы можете вызывать, setVisible(wantToSee)а не использовать ifоператор.
3. Если у вас есть несколько похожих функций, setX()формат обобщается, поэтому вы можете иметь набор согласованных функций, в то время как подход с использованием глаголов порождает множество функций, которые может быть трудно найти, если вы не знаете, что ищете. Согласованность API-интерфейсов значительно облегчает их изучение и запоминание.

Это зависит от того, что значит показать и скрыть в контексте. Сначала вы хотите выяснить, какой из них является вашим «основным путем», и сосредоточиться на разработке этого:

• Причины выбрать setVisible(bool)
  • Это просто простой переворот, или ваш объект в основном удерживает состояние
  • Ваш объект будет проводить большую часть своего времени в рамках CRUD
  • Существует много легко разделяемого кода между показом и скрытием
• Причины выбрать show()иhide()
  • Существуют важные побочные эффекты или большое количество выполняемой логики, например, когда объект должен проверять все свои контейнеры на предмет их состояния видимости или запускает анимацию перехода.
  • Является ли это частью модели предметной области, где важно выразить намерение

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

• Удобство setVisible(bool)
  • Позволяет избежать операторов if, которые имеют тривиальные условия и влияют только на видимость (напр. setVisible(a==b))
  • Может быть подключен к определенным средам получения / установки, если вы ожидаете, что это произойдет
• Удобство show()иhide()
  • Полезно в языке с первоклассными функциями и обратными вызовами (напр. onSuccess(widget.show))
  • Намного легче читать с трассировкой стека и профилированием производительности, так как вы можете быстро увидеть, что программа пыталась сделать

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

Я бы сказал "все три".

Show()и, Hide()как правило, легче впасть, чем SetVisible(true)и SetVisible(false). Однако, когда вы хотите установить видимость логически, лучше иметь метод, который принимает, boolа не создает ifвокруг него bool.

Вы можете поддерживать все три, не дублируя логику и минимальный шаблон:

void Show() {
    foo.Show();
    bar.Show();
}

void Hide() {
    foo.Hide();
    bar.Hide();
}

void SetVisible(bool visible) {
    if (visible) {
        Show();
    } else {
        Hide();
    }
}

В качестве альтернативы, если вещи, которые вы упаковываете, имеют более SetVisible-рочный API:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

void SetVisible(bool visible) {
    foo.SetVisible(visible);
    bar.SetVisible(visible);
}

Я предпочитаю show () и hide (), фактически каждый метод, который получает один логический тип, может быть изменен на два метода, которые лучше выражают намерение API. Например, Роберт Мартин в чистом коде рекомендует отдавать предпочтение методам без аргументов по сравнению с методами с одним аргументом.

Другим важным аргументом для меня является удобочитаемость, на мой взгляд, хороший код можно читать как прозу, его действительно странную прозу, например, «main_window setVisible false» вместо «main_window hide», вы пишете или говорите так обычно? построение языка в программном обеспечении, когда вполне возможно использовать более естественный язык?

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

Дело 1:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  customerPanel.setVisible(customer.isCustomerEnabled());
}

Случай 2:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  //always show customer panel
  customerPanel.setVisible(true);
}

В первом случае ясно, что делает функция setVisible, но если вы хотите прочитать ее, вы скажете:

установите панель клиента видимой, если клиент включен, или установите ее скрытой, если клиент отключен.

Хотя более информативно сказать:

• проверить статус клиента:
  • если клиент включен, то показать панель клиента
  • в противном случае скрыть это

который изменит функцию «Случай 1» на следующее:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  if(customer.isCustomerEnabled()){
    customerPanel.Show();
  }
  else{
    customerPanel.Hide();
  }
}

он производит больше кода, но более читабелен.

Во втором случае есть очевидный недостаток: вы уже знаете, что хотите показать панель, так почему бы не использовать функцию «Показать»?

Я не говорю, что использование «setVisible» является абсолютно неправильным, но это сбивает с толку, когда вы пытаетесь прочитать код, не написанный вами с течением времени, и это не соответствует правилу «Функция должна выполнять только одну операцию».

Я полагаю, что Hide()/ Show()альтернатива привлекательна, потому что легче понять, что происходит, чем когда с ней SetVisible(true), хотя наличие единственной функции предпочтительнее, потому что она избегает множества условий.

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

Используя соглашения об именах Java, вы могли бы иметь setVisible(Visibility.VISIBLE)или setVisible(Visibility.HIDDEN).

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

Когда я вижу код, который говорит «setXXX», я читаю это, чтобы сказать, что он устанавливает значение для чего-либо, я не ожидаю, что это будет иметь побочные эффекты в этом, кроме установки этого значения, и я ожидаю, что это будет идемпотентным (т.е. я могу продолжать устанавливать его с тем же значением, и это нормально). Это скорее как доступ к полю. Как правило, я бы также ожидал увидеть метод getXXX вместе с setXXX.

Я не знаю, ожидаете ли вы этого в Java и C ++, но это то, что я ожидал бы в C #, хотя в C # есть сокращение для этого, называемое Properties. И вот несколько хороших советов о том, как использовать свойства ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

Учитывая это представление, интерфейс, который я бы выбрал, зависит исключительно от наличия побочных эффектов (кроме изменения значения этого поля):

Если выполнение действия имеет побочные эффекты, например, оно показывает диалоговое окно, тогда я бы выбрал «Показать ()» и «Скрыть ()».

Если у него нет побочных эффектов, скажем, я устанавливаю видимость «виджета», а что-то еще отображает этот виджет в зависимости от его состояния, тогда я бы использовал setVisibility или setIsVisible. (Я бы не назвал это SetVisible).

В C # (не уверен в Java) довольно распространено использование шаблона наблюдателя, в котором инфраструктура пользовательского интерфейса будет прослушивать изменения объектов и автоматически повторно отображать пользовательский интерфейс при изменении свойства, такого как Visibility. Это означает, что установка значения путем вызова setIsVisible выглядит так, как будто у него есть побочные эффекты, но в моем определении это не так. Контракт виджета выполняется путем установки значения его поля, представляющего «IsVisible».

Другими словами, я могу переключать видимость метки в форме перед ее отображением. Т.е. label.getIsVisible == true, но форма не отображается.

Я не могу вызывать Hide (), когда форма не отображается.

Я бы предложил немного измененный интерфейс:

Show();
Hide();
ToggleVisible();
ToggleVisible(bool visible);

Лучшие имена

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

Уменьшенная избыточность кода

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

• Вам, вероятно, потребуется какой-то SetVisible()приватный метод, чтобы выполнить реальную работу за кулисами (или написать избыточный код для Show()и Hide()).
• Вызывающий код может иметь много избыточных блоков if / else только для того, чтобы выбрать, какой метод использовать. Это раздувает код по моему мнению.
• Если бы я был потребителем, я бы просто написал свою собственную функцию-обертку, которая делает то, что SetVisible()(или Toggle()) уже делает, чтобы избежать раздувания кода (я ненавижу избыточный код). Таким образом, дублируется метод, который, вероятно, уже существует как частный метод в реализации.

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

Если скрытие и повторное отображение объекта может иметь побочные эффекты, такие как изменение порядка Z, такие действия, скорее всего, следует выполнять отдельными методами. В таких случаях полезность внешних методов, которые принимают параметр «видимости», будет ограничена, и поэтому будет мало преимуществ для их облегчения. Кроме того, SetVisibleметод (ошибочно) предполагает, что изменения видимости объектов могут быть выполнены без побочных эффектов.