¿Es mejor Show () + Hide () o SetVisible (bool visible)?

¿Qué es mejor y por qué? (Desde el punto de vista del diseño de la interfaz):

a) Tener dos Show()y Hide()funciones

b) Tener una SetVisible(bool visible)función

EDITAR: Por ejemplo, algún objeto tiene estado de visibilidad y esta función se utiliza para cambiarlo.

c) tener los tres Show(), Hide(), SetVisible(bool visible)funciones

Prefiero SetVisible(bool visible), porque me permite escribir código de cliente como este:

SetVisible(DetermineIfItShouldBeVisible());

en lugar de tener que escribir

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

El SetVisibleenfoque también puede permitir una implementación más fácil. Por ejemplo, si una clase concreta en particular simplemente delega el método a sus clases compuestas, SetVisiblesignifica un método menos para implementar.

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

No estoy de acuerdo con todos los carteles que sugieren que múltiples funciones para hacer lo mismo es algo bueno. Mientras tres funciones en lugar de uno pueden no parecer mucho, hinchazón, recuerde que su clase es probable que terminan con muchas de esas funciones (por ejemplo setEnabled, enable, disable) y por lo tanto este enfoque va a terminar con una gran interfaz de la clase más grande. Además, es probable que termines con un montón de funciones / propiedades de sonido similares / lo que sea en tu clase y la multiplicación de funciones oscurecerá aún más cuál va con qué.

En los lenguajes que admiten propiedades, estos deberían ser preferidos, pero como Java o C ++ no lo hacen, supongo que es un punto discutible.

Creo que setVisible()debería preferirse por estos motivos:

1. Es inmediatamente obvio cuál es la función inversa. Para revertir setVisible(false)tu llamada, setVisible(true)mientras que lo contrario de hide()podría ser fácilmente reveal().
2. Es programáticamente más simple siempre que esté determinando qué estado debería tomar en el código, es decir, puede llamar en setVisible(wantToSee)lugar de usar una ifdeclaración.
3. Una vez que tiene múltiples funciones similares, el setX()formato se generaliza para que pueda tener un conjunto de funciones consistentes, mientras que el enfoque verbed genera una serie de funciones que pueden ser difíciles de localizar si no sabe lo que está buscando. La consistencia en las API las hace considerablemente más fáciles de aprender y recordar.

Depende de qué mostrar y ocultar significa en el contexto. Primero, desea averiguar cuál es su "camino principal" y centrarse en desarrollar eso:

• Razones para escoger setVisible(bool)
  • Es solo un simple giro de bits, o su objeto está principalmente en estado de retención
  • Su objeto va a pasar la mayor parte de su tiempo en un marco CRUD
  • Hay mucho código fácil de compartir entre mostrar y ocultar
• Razones para escoger show()yhide()
  • Se están ejecutando importantes efectos secundarios o mucha lógica, como cuando el objeto tiene que verificar todos sus contenedores para ver su estado de visibilidad o desencadenar una animación de transición.
  • ¿Es parte de un modelo de dominio donde es importante expresar la intención?

Bien, ahora que ha codificado el núcleo del "estándar de oro", debe averiguar si vale la pena agregar métodos de conveniencia delgados en el otro estilo, para facilitar la vida de quien vaya a usar su objeto.

• Conveniencia de setVisible(bool)
  • Le permite evitar declaraciones if que tienen condiciones triviales y solo afectan la visibilidad (ej. setVisible(a==b))
  • Puede conectarse a ciertos marcos getter / setter, si eso es algo que espera que suceda
• Conveniencia de show()yhide()
  • Útil en un lenguaje con funciones y devoluciones de llamada de primera clase (ej. onSuccess(widget.show))
  • Mucho más fácil de leer con rastros de pila y perfiles de rendimiento, ya que puede ver rápidamente lo que el programa estaba tratando de hacer.

TLDR: descubra cuál es el más importante, impleméntelo y luego pregúntese si vale la pena agregar el otro estilo como métodos convenientes.

Yo diría "los tres".

Show()y Hide()tienden a ser más fáciles de asimilar que SetVisible(true)y SetVisible(false). Sin embargo, cuando desea establecer la visibilidad de forma lógica, es mejor tener un método que tome boolun ifentorno en lugar de construirlo bool.

Puede admitir los tres sin duplicar la lógica y un mínimo repetitivo:

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

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

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

Alternativamente, si las cosas que está envolviendo tienen una SetVisibleAPI más -ish:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

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

Prefiero show () y hide (), de hecho, cada método que recibe un booleano se puede cambiar por dos métodos para expresar mejor la intención de la API. Por ejemplo, Robert Martin en código limpio recomienda métodos preferidos con cero argumentos sobre métodos con un argumento.

Otro argumento importante para mí es la legibilidad, en mi opinión, un buen código se puede leer como prosa, es una prosa realmente extraña, algo así como "main_window setVisible false" en lugar de "main_window hide", ¿escribe o habla así normalmente ?, ¿por qué usar este extraño? ¿La construcción del lenguaje en programas de software cuando es perfectamente posible utilizar un lenguaje más natural?

Creo que cuanto más expresivo sea el método, más legible y, en consecuencia, sostenible, será el código. Considere los siguientes dos casos:

Caso 1:

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

Caso 2:

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

En el primer caso, está claro qué está haciendo la función "setVisible", pero si desea leerla, diría:

configure el panel del cliente como visible si el cliente está habilitado o configúrelo como oculto si el cliente está deshabilitado.

Si bien es más descriptivo decir:

• verificar el estado del cliente:
  • si el cliente está habilitado, muestre el panel del cliente
  • de lo contrario, escóndelo

que cambiará la función "Caso 1" a la siguiente:

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

Produce más código, pero es más legible.

El segundo caso tiene una falla obvia, que ya sabe que desea mostrar el panel, entonces, ¿por qué no usar la función "Mostrar"?

No estoy diciendo que usar "setVisible" sea absolutamente incorrecto, pero se vuelve confuso cuando intentas leer el código que no escribiste a lo largo del tiempo, y no se ajusta a la regla "Una función debe realizar una sola operación".

Creo que la alternativa Hide()/ Show()es atractiva porque es más fácil de entender lo que está sucediendo que con SetVisible(true), mientras que tener una sola función es preferible porque evita muchos condicionales.

Si ese es el caso, sugiero usar una enumeración como entrada para SetVisibleque obtenga SetVisible(Visibility.Visible)o SetVisible(Visibility.Hidden). Tiene una única función: puede leer instantáneamente qué acción se está tomando.

Usando las convenciones de nomenclatura de Java, tendría quizás setVisible(Visibility.VISIBLE)o setVisible(Visibility.HIDDEN).

Estoy de acuerdo con la respuesta de Darien, pero quería agregar un punto de vista desde la perspectiva de los programadores de C #.

Cuando veo un código que dice 'setXXX', lo leo para decir que está estableciendo un valor en una cosa, no espero que tenga efectos secundarios en esa cosa que no sea establecer ese valor, y espero que esto sea idempotente (es decir, puedo seguir configurándolo con el mismo valor y está bien). Es más bien como acceder a un campo. En general, también esperaría ver un método 'getXXX' junto con un 'setXXX'.

No sé si esto es lo que esperas en Java y C ++, pero eso es lo que esperaría en C #, aunque en C # hay una pequeña mano para esto llamada Propiedades. Y aquí hay una buena guía sobre cómo usar Propiedades ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

Dada esta vista, la interfaz que elegiría depende únicamente de si hay algún efecto secundario (además de cambiar el valor de ese campo):

Si realizar la acción tiene efectos secundarios, por ejemplo, se muestra un cuadro de diálogo, iría con "Mostrar ()" y "Ocultar ()".

Si no tiene efectos secundarios, digamos que estoy configurando la visibilidad de un "widget" y algo más representa ese widget dependiendo de su estado, entonces usaría setVisibility o setIsVisible. (No lo llamaría SetVisible).

En C # (no estoy seguro acerca de Java) es bastante común adoptar un patrón de observador, donde un marco de la interfaz de usuario escuchará los cambios en los objetos y volverá a representar automáticamente la interfaz de usuario cuando cambie una propiedad como Visibilidad. Eso significa que establecer el valor al llamar a setIsVisible parece tener efectos secundarios, pero en mi definición no lo tiene. El contrato del widget se cumple estableciendo su valor de campo que representa "IsVisible".

Dicho de otra manera, está bien para mí alternar la visibilidad de una etiqueta en un formulario antes de que se muestre el formulario. Es decir, label.getIsVisible == verdadero, pero el formulario no se muestra.

No está bien que llame a Hide () cuando no se muestra el formulario.

Sugeriría una interfaz ligeramente modificada:

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

Mejores nombres

Estos nombres de métodos ayudan al desarrollador a decidir qué método usar en función de lo que debe hacerse. Mientras que SetVisible(bool visible)puede confundir a un desarrollador porque transmite el mismo significado semántico que Show()e Hide(), Toggle()implica la existencia de una condición que determina la acción. Por lo tanto, se vuelve intuitivo para el desarrollador cuándo usar cada método.

Redundancia de código reducida

El beneficio de tener múltiples métodos en su interfaz es que simplifica el código de llamada. Podrías exponer Show()y Hide(), pero:

• Probablemente requiera algún tipo de SetVisible()método privado para hacer el trabajo real detrás de escena (o escribir código redundante para Show()y Hide()).
• El código de llamada puede tener muchos bloques if / else redundantes solo para elegir qué método usar. Esto hincha el código en mi opinión.
• Si yo fuera el consumidor, probablemente escribiría mi propia función de envoltura que hace lo que SetVisible()(o Toggle()) ya hace para evitar la acumulación de código (odio el código redundante). Por lo tanto, duplicar un método que probablemente ya existe como método privado en la implementación.

Sugeriría usar, SetVisible(bool)si lo hubiera, solo si alterna la visibilidad dos veces (mostrar y volver a ocultar, u ocultar y volver a mostrar) dejaría las cosas esencialmente en el mismo estado que antes de que se realizara la operación (está bien si se muestra y se vuelve a ocultar algo o viceversa deja objetos que necesitan un redibujo, siempre que se pueda esperar que suceda "automáticamente"). Si esconder y mostrar un objeto no tendrá otro efecto que cambiar un bit de estado, entonces tendría sentido para el código externo tener algunos métodos que acepten un parámetro de visibilidad, y la escritura de dicho código se facilitará SetVisible.

Si ocultar y volver a mostrar un objeto puede tener efectos secundarios, como cambiar el orden Z, es más probable que tales acciones se realicen por métodos separados. En tales casos, la utilidad de los métodos externos que aceptan un parámetro de "visibilidad" será limitada y, por lo tanto, habrá pocas ventajas para facilitarlos. Además, un SetVisiblemétodo sugerirá (erróneamente) que los cambios en la visibilidad de los objetos se pueden lograr sin efectos secundarios.