Perché usare un bool su più astrazioni specifiche del dominio

What is the advantage to returning a boolean from a function over returning something like a enumeration of named values?

Permette ai programmatori di essere pigri. A volte questa è una virtù . Cose come questa, non lo è.

Il vantaggio principale è che al call-site, l'uso di un bool è spesso più leggibile:

if(foo.IsBar){ ... }

Piuttosto che:

if(foo.Bar == enum.Good){ ... }

L'enum sarà marginalmente più leggibile in Bar rispetto a IsBar , ma quel codice è solo in un punto. La proprietà / funzione sarà chiamata in più punti, quindi preferiamo rendere quel codice più leggibile.

E poi c'è il fatto che tutto il resto già usa bool. Se hai bisogno di prendere il risultato e di trasmetterlo nel codice esistente, l'enumerazione deve essere adattata ad alcuni valori di verità, danneggiando ulteriormente la leggibilità.

Anche in questo caso in generale . Solitamente i booleani + il buon nome possono essere resi più leggibili. A volte le enumerazioni saranno più leggibili. Utilizza quello giusto per il problema in questione.

Un motivo molto grande per questo è probabilmente il supporto: molte lingue e librerie sono progettate per supportare booleani o valori dicotomici generici su varianti più specifiche in modo che abbiano la più ampia applicabilità.

Ad esempio: if supporta i booleani. Se volessimo if per essere in grado di supportare qualsiasi dicotomia (ignorando i confronti di uguaglianza sui valori) allora probabilmente dovremmo essere parametrizzati ( if<OpReuslt,Success>(...) ) o dover testare usando una sorta di Dichotomy tipo classe / interfaccia che dovremmo implementare per tutto quello che volevamo essere testabile (nel qual caso sarebbe ancora usato qualcosa di comune a tutto, come un booleano). Entrambi sembrano PITA.

In Haskell, F #, ecc, c'è il tipo di dati algebrico Either ( Choice in F #) per rappresentare uno dei due valori possibili. Ci sono molte librerie che usano questi costrutti per interfacciarsi con il resto di un programma. Se ognuno ha provato a utilizzare la propria astrazione, dovrebbero tutti supportare le astrazioni degli altri o si dovrebbe avere una sorta di livello di conversione.

C'è anche il fatto che i valori booleani sono spesso usati in una sorta di calcolo algebrico e se è stato usato qualcos'altro dovrebbero essere convertiti in un tipo comune prima che questi calcoli possano aver luogo, quindi perché non usare i booleani per iniziare con?

Qualsiasi tipo di dati può essere pensato come in grado di contenere la risposta a una domanda. Cosa sono due più due? L'intero quattro. Cos'è pi? Il punto fluttuante con un certo pattern di bit. Il cielo è blu? Una risposta sì / no, vera / falsa.

Questi sono primitivi , il che significa che gli elementi dei dati sono riutilizzabili in un ampio spettro di usi e generalmente sono semplici, spesso adatti a un singolo registro della CPU. Ogni funzione che calcola un intero ha bisogno del proprio enum o della propria struttura dati personalizzata? No. Ogni funzione che restituisce una risposta sì / no ha bisogno dello stesso? No.

A volte una funzione deve restituire un numero discreto di risposte. Se ci sono più di due risposte, usa un enum. Se ci sono due risposte valide e non sono sì / no o vero / falso, utilizzare un enum (ad esempio rosso / verde, fine settimana / giorno della settimana, fatturabile / non fatturabile). Se le risposte sono vere o false, usa un valore booleano. Ecco perché esiste.

A volte devi solo sapere se un'operazione è riuscita o meno.

L'esempio più diretto che posso pensare è la metrica TryParse in .NET Framework. TryParse esiste per una serie di motivi:

1. Puoi controllare la durata della variabile in cui stai inserendo il risultato dell'analisi,
2. Le eccezioni sono troppo costose per essere lanciate se ti trovi nel bel mezzo di un ciclo lungo e
3. Un flag di successo consente di sostituire un valore appropriato per un analisi fallita (come zero, forse).

TryParse si presenta così:

bool result SomeNumericType.TryParse(string text, out SomeNumericType value)

Diciamo che stai cercando di analizzare alcune colonne numeriche in un grande file di testo il più rapidamente possibile, ma una delle colonne contiene un carattere di testo. Se utilizzi un metodo Parse che genera eccezioni, hai appena azzoppato il parser.

D'altra parte, se fai qualcosa di simile:

public double ParseColumn(string text)
{
    double number= 0;
    if (double.TryParse(text), out number)
        return number;
    else
    {
        // optionally analyze text for the reasons why, log the problem, or whatever
        return 0;
    }
}

Quindi hai evitato di dover intercettare l'eccezione temuta, un'operazione che è in genere di tre ordini di grandezza più lenta di restituire un codice di errore o un risultato positivo, e hai abbassato il sovraccarico per quanto umanamente possibile per il caso generale (un'operazione di analisi riuscita).

Perché la risposta del dominio è solo un altro booleano. LetterSent, BillPaid, AccountIsPastDue, SubscribedToAutoPay, ecc ...

Quando parli con gli esperti del dominio, è così che pensano della situazione - la differenza principale è che in genere pensano in termini sì / no e non vero / falso, ma creare un oggetto sarebbe sciocco - Fondamentalmente un sacco di lavoro extra per un semplice metodo ToString.