È meglio Show () + Hide () o SetVisible (bool visibile)?

Cosa è meglio e perché? (Dal punto di vista dell'interfaccia):

a) Avere due Show()e Hide()funzioni

b) Avere una SetVisible(bool visible)funzione

EDIT: Ad esempio alcuni oggetti hanno uno stato di visibilità e questa funzione viene utilizzata per cambiarlo.

c) Per avere tutti e tre Show(), Hide(), SetVisible(bool visible)funzioni

Preferisco SetVisible(bool visible), perché mi permette di scrivere il codice client in questo modo:

SetVisible(DetermineIfItShouldBeVisible());

invece di dover scrivere

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

L' SetVisibleapproccio può anche consentire una più facile implementazione. Ad esempio, se una determinata classe concreta delega semplicemente il metodo alle sue classi composte, SetVisiblesignifica implementare un metodo in meno.

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

Non sono d'accordo con tutti i poster che suggeriscono che più funzioni per fare la stessa cosa siano buone. Mentre tre funzioni invece di uno non possono sembrare molto gonfiare, ricordate che la vostra classe rischia di finire con molte di queste funzioni (ad esempio setEnabled, enable, disable) e quindi questo approccio si concluderà con un molto più interfaccia di classe più grande. Inoltre, è probabile che finirai con un mucchio di funzioni / proprietà / proprietà / suoni simili nella tua classe e la moltiplicazione delle funzioni oscurerà ulteriormente quale si accompagna a cosa.

Nei linguaggi che supportano le proprietà, questi dovrebbero essere preferiti, ma dal momento che né Java né C ++ lo fanno, immagino che sia un punto controverso.

Penso che setVisible()dovrebbe essere preferito per questi motivi:

1. È immediatamente ovvio quale sia la funzione inversa. Per invertire la setVisible(false)chiamata, setVisible(true)mentre l'opposto di hide()potrebbe essere facilmente reveal().
2. È programmaticamente più semplice ogni volta che si determina lo stato che deve assumere nel codice, ovvero è possibile chiamare setVisible(wantToSee)anziché utilizzare ifun'istruzione.
3. Una volta che hai più funzioni simili, il setX()formato si generalizza in modo da poter avere una serie di funzioni coerenti mentre l'approccio verbale genera una serie di funzioni che possono essere difficili da individuare se non sai cosa stai cercando. La coerenza nelle API le rende notevolmente più facili da imparare e ricordare.

Dipende da cosa significa mostrare e nascondere nel contesto. Prima di tutto devi capire qual è il tuo "modo principale" e concentrarti sullo sviluppo di questo:

• Motivi per scegliere setVisible(bool)
  • È solo un semplice capovolgimento, o il tuo oggetto ha principalmente lo stato di conservazione
  • Il tuo oggetto trascorrerà la maggior parte del suo tempo in un framework CRUD
  • C'è molto codice facilmente condivisibile tra mostrare e nascondere
• Ragioni per scegliere show()ehide()
  • Esistono importanti effetti collaterali o molta logica in esecuzione, ad esempio quando l'oggetto deve controllare tutti i suoi contenitori per il loro stato di visibilità o innesca un'animazione di transizione.
  • Fa parte di un modello di dominio in cui è importante esprimere l' intenzione

OK, quindi ora che hai codificato il suo nucleo "gold standard", devi capire se vale la pena aggiungere sottili metodi di convenienza nell'altro stile, per rendere la vita più facile a chiunque userà il tuo oggetto.

• Convenienza di setVisible(bool)
  • Ti consente di evitare dichiarazioni if ​​che hanno condizioni insignificanti e influiscono solo sulla visibilità (es. setVisible(a==b))
  • Può essere cablato in determinati framework getter / setter, se è qualcosa che ti aspetti che accada
• Convenienza di show()ehide()
  • Utile in una lingua con funzioni e callback di prima classe (es. onSuccess(widget.show))
  • Molto più facile da leggere con le tracce dello stack e la profilazione delle prestazioni, poiché puoi vedere rapidamente cosa stava cercando di fare il programma

TLDR: scopri qual è il più importante, implementalo e poi chiediti se vale la pena aggiungere l'altro stile come metodi di convenienza.

Direi "tutti e tre".

Show()e Hide()tendono ad essere più facili da grok di SetVisible(true)e SetVisible(false). Tuttavia, quando si desidera impostare la visibilità logicamente, è meglio avere un metodo che prenda un metodo boolpiuttosto che costruirlo ifattorno bool.

Puoi supportare tutti e tre senza duplicare la logica e il minimo boilerplate:

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

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

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

In alternativa, se le cose che stai avvolgendo hanno SetVisibleun'API più -ish:

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

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

Preferisco show () e hide (), infatti, ogni metodo che riceve un booleano può essere modificato per due metodi tan che esprimono meglio l'intenzione dell'API. Ad esempio Robert Martin in codice pulito consiglia di preferire metodi con argomenti zero rispetto ai metodi con un argomento.

Un altro argomento importante per me è la leggibilità, secondo me il buon codice può essere letto come la prosa, la sua prosa davvero strana è qualcosa come "main_window setVisible false" invece di "main_window hide", scrivi o parli normalmente?, Perché usare questo strano costruzione del linguaggio nei programmi software quando è perfettamente possibile usare un linguaggio più naturale ?.

Credo che più il metodo è espressivo, più leggibile e, di conseguenza, mantenibile il codice sarà. Considera i seguenti due casi:

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

Nel primo caso, è chiaro cosa sta facendo la funzione "setVisible", ma se vuoi leggerlo, dovresti dire:

impostare il pannello del cliente su visibile se il cliente è abilitato o impostarlo su nascosto se il cliente è disabilitato.

Mentre è più descrittivo dire:

• controllare lo stato del cliente:
  • se il cliente è abilitato, mostra il pannello del cliente
  • altrimenti, nascondilo

che cambierà la funzione "Caso 1" nel modo seguente:

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

produce più codice, ma è più leggibile.

Il secondo caso ha un difetto evidente, ovvero sai già che vuoi mostrare il pannello, quindi perché non usare la funzione "Mostra"?

Non sto dicendo che usare "setVisible" sia assolutamente sbagliato, ma diventa confuso quando provi a leggere il codice non scritto da te nel tempo, e non è conforme alla regola "Una funzione dovrebbe eseguire una sola operazione".

Credo che l' alternativa Hide()/ Show()sia attraente perché è più facile capire cosa sta succedendo che con SetVisible(true), mentre avere una singola funzione è preferibile perché evita molti condizionali.

In tal caso, suggerisco di utilizzare un elenco come input per SetVisible, in modo da ottenere SetVisible(Visibility.Visible)o SetVisible(Visibility.Hidden). Hai un'unica funzione che puoi leggere all'istante quale azione è stata intrapresa.

Usando le convenzioni di denominazione di Java, potresti avere setVisible(Visibility.VISIBLE)o setVisible(Visibility.HIDDEN).

Concordo con la risposta di Darien, ma volevo aggiungere un punto di vista dal punto di vista dei programmatori C #.

Quando vedo il codice che dice 'setXXX', leggo che per dire che sta impostando un valore su una cosa, non mi aspetto che ciò abbia effetti collaterali in quella cosa oltre all'impostazione di quel valore, e mi aspetto che sia idempotente (cioè posso continuare a impostarlo con lo stesso valore ed è ok). È piuttosto come accedere a un campo. In genere mi aspetto anche di vedere un metodo "getXXX" insieme a un "setXXX".

Non so se questo è quello che ti aspetti in Java e C ++, ma è quello che mi aspetterei in C #, anche se in C # c'è una scorciatoia per questo chiamato Proprietà. Ed ecco alcune belle indicazioni su come usare Proprietà ( http://msdn.microsoft.com/en-us/library/ms182181.aspx ).

Dato questo punto di vista, l'interfaccia che sceglierei dipende esclusivamente dalla presenza di effetti collaterali (oltre alla modifica del valore di quel campo):

Se l'esecuzione dell'azione ha effetti collaterali, ad esempio mostra una finestra di dialogo, sceglierei "Show ()" e "Hide ()".

Se non ha effetti collaterali, supponiamo che sto impostando la visibilità di un "widget" e qualcos'altro rende quel widget in base al suo stato, quindi userei setVisibility o setIsVisible. (Non lo chiamerei SetVisible).

In C # (non sono sicuro di Java) è abbastanza comune adottare un modello di osservatore, in cui un framework dell'interfaccia utente ascolterà le modifiche agli oggetti e riattiverà automaticamente l'interfaccia quando una proprietà come Visibilità cambia. Ciò significa che l'impostazione del valore chiamando setIsVisible appare come se avesse effetti collaterali, ma nella mia definizione non lo è. Il contratto del widget viene eseguito impostando il valore del campo che rappresenta "IsVisible".

Detto in altro modo, per me va bene attivare la visibilità di un'etichetta su un modulo prima che il modulo venga mostrato. Vale a dire label.getIsVisible == true, ma il modulo non viene visualizzato.

Non va bene per me chiamare Hide () quando il modulo non viene visualizzato.

Suggerirei un'interfaccia leggermente modificata:

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

Nomi migliori

Questi nomi di metodo aiutano lo sviluppatore a decidere quale metodo utilizzare in base a ciò che deve essere fatto. Considerando che SetVisible(bool visible)può confondere uno sviluppatore perché trasmette lo stesso significato semantico di Show()e Hide(), Toggle()implica l'esistenza di una condizione che determina l'azione. Diventa quindi intuitivo per lo sviluppatore quando utilizzare ciascun metodo.

Ridondanza del codice ridotta

Il vantaggio di avere più metodi nell'interfaccia è che semplifica il codice chiamante. Potresti semplicemente esporre Show()e Hide(), ma:

• Probabilmente avresti bisogno di un qualche SetVisible()metodo privato per fare il vero lavoro dietro le quinte (o scrivere codice ridondante per Show()e Hide()).
• Il codice chiamante potrebbe avere molti blocchi if / else ridondanti solo per scegliere quale metodo usare. Questo gonfia il codice secondo me.
• Se fossi il consumatore, probabilmente scriverei la mia funzione wrapper che fa ciò che SetVisible()(o Toggle()) già fa per evitare il gonfiamento del codice (odio il codice ridondante). Duplicando così un metodo che probabilmente esiste già come metodo privato nell'implementazione.

Suggerirei di usare SetVisible(bool)se solo solo se si cambia la visibilità due volte (mostra e nascondi, o nascondi e ri-mostra) lascerebbe le cose nello stesso stato essenzialmente prima dell'operazione (va bene se mostra e nascondi qualcosa o viceversa lascia gli oggetti che necessitano di un ridisegno, purché ci si possa aspettare che accada "automaticamente"). Se nascondere e mostrare un oggetto non avrà alcun effetto se non quello di cambiare un bit di stato, allora avrebbe senso un codice esterno per avere alcuni metodi che accettano un parametro di visibilità, e la scrittura di tale codice sarà facilitata SetVisible.

Se nascondere e mostrare nuovamente un oggetto potrebbe avere effetti collaterali come la modifica dell'ordine Z, è più probabile che tali azioni vengano eseguite con metodi separati. In tali casi, l'utilità di metodi esterni che accettano un parametro di "visibilità" sarà limitata e quindi ci saranno pochi vantaggi nel facilitarli. Inoltre, un SetVisiblemetodo suggerirà (erroneamente) che le modifiche alla visibilità degli oggetti possono essere realizzate senza effetti collaterali.