È sbagliato usare un parametro booleano per determinare i valori?

Secondo È sbagliato usare un parametro booleano per determinare il comportamento? , Conosco l'importanza di evitare l'uso di parametri booleani per determinare un comportamento, ad esempio:

versione originale

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

nuova versione:

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

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

Ma che dire del caso in cui il parametro booleano viene utilizzato per determinare i valori anziché i comportamenti? per esempio:

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

Sto cercando di eliminare la bandiera isHintOn e creare 2 funzioni separate:

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

ma la versione modificata sembra meno mantenibile perché:

1. ha più codici rispetto alla versione originale

2. non può mostrare chiaramente che la visibilità di layer2 è opposta all'opzione di suggerimento

3. quando viene aggiunto un nuovo livello (ad esempio: layer4), devo aggiungere

   this.layer4.visible=false;
   

   e

   this.layer4.visible=true;  
   

   in setHintOn () e setHintOff () separatamente

Quindi la mia domanda è, se il parametro booleano viene utilizzato per determinare solo i valori, ma non i comportamenti (ad es. No if-else su quel parametro), si consiglia comunque di eliminare quel parametro booleano?

Il design dell'API dovrebbe concentrarsi su ciò che è maggiormente utilizzabile per un client dell'API, dal lato chiamante .

Ad esempio, se questa nuova API richiede al chiamante di scrivere regolarmente codice come questo

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

allora dovrebbe essere ovvio che evitare il parametro è peggio che avere un'API che consente al chiamante di scrivere

 foo.setState(flag);

La prima versione produce solo un problema che deve essere risolto sul lato chiamante (e probabilmente più di una volta). Ciò non aumenta né la leggibilità né la manutenibilità.

Il lato dell'implementazione , tuttavia, non dovrebbe dettare l'aspetto dell'API pubblica. Se una funzione come setHintcon un parametro richiede meno codice nell'implementazione, ma un'API in termini setHintOn/ setHintOffsembra più facile da usare per un client, è possibile implementarla in questo modo:

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

Quindi, sebbene l'API pubblica non abbia un parametro booleano, non esiste una logica duplicata, quindi solo un posto dove cambiare quando arriva un nuovo requisito (come nell'esempio della domanda).

Questo funziona anche al contrario: se il setStatemetodo dall'alto deve passare tra due diversi pezzi di codice, tali pezzi di codice possono essere rifattorizzati in due diversi metodi privati. Quindi IMHO non ha senso cercare un criterio per decidere tra "un parametro / un metodo" e "zero parametri / due metodi" osservando gli interni. Guarda, tuttavia, il modo in cui vorresti vedere l'API nel ruolo di consumatore.

In caso di dubbi, prova a utilizzare "test driven development" (TDD), che ti costringerà a pensare all'API pubblica e a come utilizzarla.

Martin Fowler cita Kent Beck nel raccomandare setOn() setOff()metodi separati , ma dice anche che questo non dovrebbe essere considerato inviolabile:

Se si tira i dati [sic] da una fonte booleana, ad esempio un controllo dell'interfaccia utente o fonte di dati, avrei preferito setSwitch(aValue)che

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

Questo è un esempio che un'API dovrebbe essere scritta per facilitare il chiamante, quindi se sappiamo da dove proviene il chiamante dovremmo progettare l'API tenendo a mente tali informazioni. Questo sostiene anche che a volte possiamo fornire entrambi gli stili se riceviamo i chiamanti in entrambi i modi.

Un'altra raccomandazione è quella di utilizzare un valore enumerato o un tipo di flag per dare nomi migliori truee falsespecifici per il contesto. Nel tuo esempio, showHinte hideHintpotrebbe essere migliore.

Penso che stai mescolando due cose nel tuo post, l'API e l'implementazione. In entrambi i casi non credo che ci sia una regola forte che puoi usare sempre, ma dovresti considerare queste due cose in modo indipendente (il più possibile).

Cominciamo con l'API, entrambi:

public void setHint(boolean isHintOn)

e:

public void setHintOn()
public void setHintOff()

sono valide alternative a seconda di ciò che il tuo oggetto dovrebbe offrire e di come i tuoi clienti useranno l'API. Come ha sottolineato Doc, se i tuoi utenti hanno già una variabile booleana (da un controllo UI, un'azione dell'utente, un'API esterna, ecc.) La prima opzione ha più senso, altrimenti stai solo forzando un'istruzione if in più sul codice del client . Tuttavia, se ad esempio stai cambiando il suggerimento in vero quando inizi un processo e in falso alla fine la prima opzione ti dà qualcosa del genere:

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

mentre la seconda opzione ti dà questo:

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

quale IMO è molto più leggibile, quindi andrò con la seconda opzione in questo caso. Ovviamente, nulla ti impedisce di offrire entrambe le opzioni (o più, potresti usare un enum come Graham ha detto se questo ha più senso, ad esempio).

Il punto è che dovresti scegliere la tua API in base a cosa dovrebbe fare l'oggetto e al modo in cui i client lo useranno, non in base a come lo implementerai.

Quindi devi scegliere come implementare la tua API pubblica. Diciamo che abbiamo scelto i metodi setHintOne setHintOffcome nostra API pubblica e condividono questa logica comune come nel tuo esempio. Potresti facilmente astrarre questa logica attraverso un metodo privato (codice copiato da 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);
}

Al contrario, supponiamo di aver scelto setHint(boolean isHintOn)una nostra API ma invertiamo il tuo esempio, a causa del motivo per cui l'impostazione del suggerimento On è completamente diversa dall'impostazione su Off. In questo caso potremmo implementarlo come segue:

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

O anche:

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

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

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

Il punto è che, in entrambi i casi, abbiamo prima scelto la nostra API pubblica e poi adattato la nostra implementazione per adattarla all'API prescelta (e ai vincoli che abbiamo), non viceversa.

A proposito, penso che lo stesso valga per il post che hai collegato sull'utilizzo di un parametro booleano per determinare il comportamento, vale a dire che dovresti decidere in base al tuo caso d'uso piuttosto che a una regola rigida (sebbene in quel caso particolare di solito la cosa corretta da fare è romperlo in più funzioni).

Per prima cosa: il codice non è automaticamente meno gestibile, solo perché è un po 'più lungo. La chiarezza è ciò che conta.

Ora, se hai davvero a che fare con i dati, allora quello che hai è un setter per una proprietà booleana. In tal caso potresti voler semplicemente archiviare direttamente quel valore e ricavare le visibilità del layer, ad es

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

^{(Mi sono preso la libertà di dare ai livelli nomi reali - se non lo hai nel tuo codice originale, inizierei con quello)}

Questo ti lascia ancora con la domanda se avere un setHintVisibility(bool)metodo. Personalmente, consiglierei di sostituirlo con un metodo showHint()e hideHint()- entrambi saranno davvero semplici e non dovrai cambiarli quando aggiungi i livelli. Tuttavia, non è un taglio netto giusto / sbagliato.

Ora se chiamare la funzione dovrebbe effettivamente cambiare la visibilità di quei livelli, si ha effettivamente un comportamento. In tal caso, consiglierei sicuramente metodi separati.

I parametri booleani vanno bene nel secondo esempio. Come hai già capito, i parametri booleani non sono di per sé problematici. Sta cambiando il comportamento in base a un flag, il che è problematico.

Il primo esempio è problematico, perché la denominazione indica un metodo setter, ma le implementazioni sembrano essere qualcosa di diverso. Quindi hai l'antipasto di cambio di comportamento e un metodo fuorviante. Ma se il metodo in realtà è un setter regolare (senza cambio di comportamento), allora non ci sono problemi setState(boolean). Avere due metodi setStateTrue()e setStateFalse()complicare inutilmente le cose senza alcun beneficio.

Un altro modo per risolvere questo problema è introdurre un oggetto per rappresentare ogni suggerimento e far sì che l'oggetto sia responsabile della determinazione dei valori booleani associati a quel suggerimento. In questo modo è possibile aggiungere nuove permutazioni anziché semplicemente avere due stati booleani.

Ad esempio, in Java, potresti fare:

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

E quindi il tuo codice chiamante sarebbe simile al seguente:

setHint(HintState.SHOW_HINT);

E il tuo codice di implementazione sarebbe simile al seguente:

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

Ciò mantiene conciso il codice di implementazione e il codice del chiamante, in cambio della definizione di un nuovo tipo di dati che associa chiaramente intenzioni fortemente tipizzate, denominate intenzioni ai corrispondenti set di stati. Penso che sia meglio tutto intorno.

Quindi la mia domanda è, se il parametro booleano viene utilizzato per determinare solo i valori, ma non i comportamenti (ad es. No if-else su quel parametro), si consiglia comunque di eliminare quel parametro booleano?

Quando ho dubbi su queste cose. Mi piace immaginare come sarebbe la traccia dello stack.

Per molti anni ho lavorato a un progetto PHP che utilizzava la stessa funzione di setter e getter . Se viene passato null , restituirà il valore, altrimenti impostarlo. È stato orribile con cui lavorare .

Ecco un esempio di una traccia dello stack:

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

Non avevi idea dello stato interno e questo ha reso più difficile il debug. Ci sono un sacco di altri effetti collaterali negativi, ma prova a vedere che c'è un valore nel nome di una funzione dettagliata e chiarezza quando le funzioni eseguono una singola azione.

Ora l'immagine lavora con la traccia dello stack per una funzione che ha un comportamento A o B basato su un valore booleano.

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

È confuso se me lo chiedi. Le stesse setVisiblelinee producono due diversi percorsi di traccia.

Quindi torna alla tua domanda. Prova a immaginare come apparirà la traccia dello stack, come comunica a una persona cosa sta succedendo e chiediti se stai aiutando una persona futura a eseguire il debug del codice.

Ecco alcuni consigli:

• un nome di funzione chiaro che implica l'intento senza la necessità di conoscere i valori dell'argomento.
• una funzione esegue una singola azione
• il nome implica mutazione o comportamento immutabile
• risolvere sfide di debug relative alla capacità di debug della lingua e degli strumenti.

A volte il codice sembra eccessivo al microscopio, ma quando torni all'immagine più grande un approccio minimalista lo farà scomparire. Se ne hai bisogno per distinguerti in modo da poterlo mantenere. L'aggiunta di molte piccole funzioni può sembrare eccessivamente dettagliata, ma migliora la manutenibilità se utilizzata in senso lato in un contesto più ampio.

In quasi tutti i casi in cui si passa un booleanparametro a un metodo come un flag per modificare il comportamento di qualcosa, è necessario prendere in considerazione un modo più esplicito e sicuro per farlo.

Se non fai altro che usare uno Enumche rappresenta lo stato, hai migliorato la comprensione del tuo codice.

Questo esempio usa la Nodeclasse da JavaFX:

public enum Visiblity
{
    SHOW, HIDE

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

è sempre meglio di, come si trova su molti JavaFXoggetti:

public void setVisiblity(final boolean flag);

ma penso .setVisible()e .setHidden()sono la soluzione migliore per la situazione in cui la bandiera è una booleanin quanto è la più esplicita e meno dettagliata.

nel caso di qualcosa con selezioni multiple, questo è ancora più importante per farlo in questo modo. EnumSetesiste solo per questo motivo.

Ed Mann ha un ottimo post sul blog proprio su questo argomento. Stavo per parafrasare proprio quello che dice, quindi per non duplicare lo sforzo, pubblicherò semplicemente un link al suo post sul blog come addendum a questa risposta.

Quando si decide tra un approccio per qualche interfaccia che passa un parametro (booleano) rispetto a metodi sovraccaricati senza detto parametro, consultare i client che consumano.

Se tutti gli utilizzi passassero valori costanti (es. Vero, falso), ciò sostiene i sovraccarichi.

Se tutti gli utilizzi passassero un valore variabile, ciò vale per il metodo con l'approccio con parametri.

Se nessuno di questi due estremi si applica, ciò significa che esiste un mix di usi del cliente, quindi devi scegliere se supportare entrambi i moduli o fare in modo che una categoria di clienti si adatti all'altro (che per loro è uno stile più innaturale).

Vi sono due considerazioni da progettare:

• API: quale interfaccia si presenta all'utente,
• Implementazione: chiarezza, manutenibilità, ecc ...

Non dovrebbero essere confusi.

È perfettamente bene:

• avere più metodi nel delegato API per una singola implementazione,
• disporre di un singolo metodo nell'invio dell'API a più implementazioni a seconda della condizione.

Pertanto, qualsiasi argomento che tenti di bilanciare i costi / benefici di una progettazione API con i costi / benefici di una progettazione di implementazione è discutibile e dovrebbe essere esaminato attentamente.

Dal lato API

Come programmatore, in genere preferisco le API programmabili. Il codice è molto più chiaro quando posso inoltrare un valore rispetto a quando ho bisogno di un'istruzione if/ switchsul valore per decidere quale funzione chiamare.

Quest'ultimo può essere necessario se ogni funzione prevede argomenti diversi.

Nel tuo caso, quindi, un singolo metodo setState(type value)sembra migliore.

Tuttavia , non c'è niente di peggio che senza nome true, false, 2, ecc ... quei valori magici non hanno significato in proprio. Evita l'ossessione primitiva e abbraccia la digitazione forte.

Così, da un POV API, che voglio: setState(State state).

Dal punto di vista dell'implementazione

Consiglio di fare tutto ciò che è più facile.

Se il metodo è semplice, è meglio tenerlo insieme. Se il flusso di controllo è contorto, è meglio separarlo in più metodi, ciascuno con un sotto-caso o un passaggio della pipeline.

Infine, considera il raggruppamento .

Nel tuo esempio (con spazi bianchi aggiunti per la leggibilità):

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

Perché in layer2controtendenza? È una funzionalità o è un bug?

Potrebbe essere possibile avere 2 elenchi [layer1, layer3]e [layer2], con un nome esplicito che indica il motivo per cui sono raggruppati insieme, e quindi scorrere su tali elenchi.

Per esempio:

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

Il codice parla da solo, è chiaro perché ci sono due gruppi e il loro comportamento differisce.

Separatamente dalla domanda setOn() + setOff()vs set(flag), prenderei attentamente in considerazione se un tipo booleano sia il migliore qui. Sei sicuro che non ci sarà mai una terza opzione?

Potrebbe valere la pena considerare un enum anziché un booleano. Oltre a consentire l'estensibilità, ciò rende anche più difficile ottenere il booleano in modo errato, ad esempio:

setHint(false)

vs

setHint(Visibility::HIDE)

Con l'enum, sarà molto più facile estenderlo quando qualcuno decide di voler un'opzione 'se necessario':

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

vs

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

Secondo ..., conosco l'importanza di evitare l'uso di parametri booleani per determinare un comportamento

Suggerirei di rivalutare questa conoscenza.

Prima di tutto, non vedo la conclusione che stai proponendo nella domanda SE che hai collegato. Si tratta principalmente di inoltrare un parametro su più fasi di chiamate di metodo, dove viene valutato molto lungo la catena.

Nel tuo esempio, stai valutando il parametro nel tuo metodo. A tale proposito, non differisce affatto da nessun altro tipo di parametro.

In generale, non c'è assolutamente nulla di sbagliato nell'uso dei parametri booleani; e ovviamente qualsiasi parametro determinerà un comportamento, o perché dovresti averlo in primo luogo?

Definire la domanda

La tua domanda sul titolo è "È sbagliato [...]?" - ma cosa intendi con "sbagliato"?

Secondo un compilatore C # o Java, non è sbagliato. Sono certo che ne sei consapevole e non è quello che stai chiedendo. Temo a parte questo, abbiamo solo nprogrammatori n+1opinioni diverse. Questa risposta presenta ciò che il libro Clean Code ha da dire al riguardo.

Risposta

Clean Code è un valido argomento contro gli argomenti delle funzioni in generale:

Gli argomenti sono difficili. Prendono molto potere concettuale. [...] i nostri lettori avrebbero dovuto interpretarlo ogni volta che lo vedevano.

Un "lettore" qui può essere il consumatore API. Può anche essere il prossimo programmatore, che non sa ancora cosa fa questo codice - che potresti essere tu tra un mese. O passeranno attraverso 2 funzioni separatamente o attraverso 1 funzione due volte , una volta mantenute truee una volta falsein mente.
In breve, usa il minor numero di argomenti possibile .

Il caso specifico di un argomento flag viene successivamente affrontato direttamente:

Gli argomenti della bandiera sono brutti. Passare un booleano in una funzione è una pratica davvero terribile. Ciò complica immediatamente la firma del metodo, proclamando a gran voce che questa funzione fa più di una cosa. Fa una cosa se la bandiera è vera e un'altra se la bandiera è falsa!

Per rispondere direttamente alle tue domande:
secondo Clean Code , si consiglia di eliminare quel parametro.

Informazioni addizionali:

Il tuo esempio è piuttosto semplice, ma anche lì puoi vedere la semplicità propagarsi al tuo codice: le funzioni senza parametri eseguono solo compiti semplici, mentre l'altra funzione deve fare l'aritmetica booleana per raggiungere lo stesso obiettivo. È banale aritmetica booleana in questo esempio semplificato, ma potrebbe essere piuttosto complessa in una situazione reale.

Ho visto molti argomenti qui che dovresti renderlo dipendente dall'utente API, perché doverlo fare in molti posti sarebbe stupido:

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

Io non sono d'accordo che qualcosa non ottimale che sta accadendo qui. Forse è troppo ovvio da vedere, ma la tua prima frase menziona "l'importanza di evitare di usare parametri booleani per determinare un comportamento" e questa è la base dell'intera domanda. Non vedo un motivo per rendere quella cosa che è brutta da fare più facile per l'utente API.

Non so se esegui dei test - in tal caso, considera anche questo:

Gli argomenti sono ancora più difficili da un punto di vista sperimentale. Immagina la difficoltà di scrivere tutti i casi di test per garantire che tutte le varie combinazioni di argomenti funzionino correttamente. Se non ci sono argomenti, questo è banale.