Come posso effettuare una chiamata con un clearer booleano? Trappola Booleana

Come notato nei commenti di @ benjamin-gruenbaum, questa è chiamata la trappola booleana:

Di 'che ho una funzione come questa

UpdateRow(var item, bool externalCall);

e nel mio controller, quel valore per externalCallsarà sempre VERO. Qual è il modo migliore per chiamare questa funzione? Di solito scrivo

UpdateRow(item, true);

Ma chiedo a me stesso, dovrei dichiarare un valore booleano, solo per indicare che cosa rappresenta quel valore "vero"? Puoi saperlo guardando la dichiarazione della funzione, ma è ovviamente più veloce e più chiaro se hai appena visto qualcosa di simile

bool externalCall = true;
UpdateRow(item, externalCall);

PD: Non sono sicuro che questa domanda si adatti davvero qui, in caso contrario, dove posso ottenere maggiori informazioni su questo?

PD2: Non ho taggato nessuna lingua perché pensavo fosse un problema molto generico. In ogni caso, lavoro con c # e la risposta accettata funziona per c #

Non c'è sempre una soluzione perfetta, ma hai molte alternative tra cui scegliere:

• Usa argomenti con nome , se disponibili nella tua lingua. Funziona molto bene e non presenta particolari inconvenienti. In alcune lingue, qualsiasi argomento può essere passato come argomento denominato, ad esempio updateRow(item, externalCall: true)( C # ) o update_row(item, external_call=True)(Python).

  Il tuo suggerimento di utilizzare una variabile separata è un modo per simulare argomenti con nome, ma non ha i vantaggi di sicurezza associati (non c'è garanzia che tu abbia usato il nome di variabile corretto per quell'argomento).

• Usa funzioni distinte per la tua interfaccia pubblica, con nomi migliori. Questo è un altro modo di simulare i parametri nominati, inserendo i valori del paremetro nel nome.

  Questo è molto leggibile, ma porta a molta piastra di caldaia per te, che stai scrivendo queste funzioni. Inoltre, non può affrontare bene l'esplosione combinatoria quando ci sono più argomenti booleani. Uno svantaggio significativo è che i client non possono impostare questo valore in modo dinamico, ma devono usare if / else per chiamare la funzione corretta.

• Usa un enum . Il problema con i booleani è che sono chiamati "vero" e "falso". Quindi, invece, introdurre un tipo con nomi migliori (ad esempio enum CallType { INTERNAL, EXTERNAL }). Come ulteriore vantaggio, questo aumenta la sicurezza dei tipi del tuo programma (se la tua lingua implementa enum come tipi distinti). Lo svantaggio di enum è che aggiungono un tipo alla tua API visibile pubblicamente. Per funzioni puramente interne, questo non ha importanza e gli enum non hanno svantaggi significativi.

  In lingue senza enumerazioni, a volte vengono utilizzate stringhe brevi . Funziona e potrebbe persino essere migliore dei booleani grezzi, ma è molto sensibile agli errori di battitura. La funzione dovrebbe quindi affermare immediatamente che l'argomento corrisponde a una serie di valori possibili.

Nessuna di queste soluzioni ha un impatto sulle prestazioni proibitivo. I parametri nominati e gli enum possono essere risolti completamente al momento della compilazione (per un linguaggio compilato). L'uso delle stringhe può comportare un confronto delle stringhe, ma il costo è trascurabile per i letterali di stringhe piccole e la maggior parte dei tipi di applicazioni.

La soluzione corretta è fare ciò che suggerisci, ma impacchettalo in una mini-facciata:

void updateRowExternally() {
  bool externalCall = true;
  UpdateRow(item, externalCall);
}

La leggibilità supera la micro-ottimizzazione. Puoi permetterti la chiamata di funzione extra, sicuramente meglio di quanto ti possa permettere lo sforzo degli sviluppatori di dover cercare la semantica della bandiera booleana anche una volta.

Supponiamo che io abbia una funzione come UpdateRow (var item, bool externalCall);

Perché hai una funzione come questa?

In quali circostanze lo chiameresti con l'argomento externalCall impostato su valori diversi?

Se uno proviene da un'applicazione client esterna e l'altro è all'interno dello stesso programma (ovvero moduli di codice diversi), direi che dovresti avere due metodi diversi , uno per ogni caso, possibilmente anche definiti su distinti interfacce.

Se, tuttavia, stavi effettuando la chiamata in base a un dato prelevato da una fonte non di programma (ad esempio, un file di configurazione o una lettura del database), il metodo di passaggio booleano avrebbe più senso.

Anche se concordo sul fatto che sia ideale utilizzare una funzionalità linguistica per rafforzare la leggibilità e la sicurezza del valore, puoi anche optare per un approccio pratico : i commenti al momento della chiamata. Piace:

UpdateRow(item, true /* row is an external call */);

o:

UpdateRow(item, true); // true means call is external

o (giustamente, come suggerito da Frax):

UpdateRow(item, /* externalCall */true);

1. Puoi "nominare" i tuoi bool. Di seguito è riportato un esempio per un linguaggio OO (dove può essere espresso nella classe che fornisce UpdateRow()), tuttavia il concetto stesso può essere applicato in qualsiasi lingua:

   class Table
   {
   public:
       static const bool WithExternalCall = true;
       static const bool WithoutExternalCall = false;
   

   e nel sito di chiamata:

   UpdateRow(item, Table::WithExternalCall);
   

2. Credo che l'articolo n. 1 sia migliore, ma non impone all'utente di utilizzare nuove variabili quando utilizza la funzione. Se la sicurezza dei tipi è importante per te, puoi crearne uno enume farlo UpdateRow()accettare invece di bool:

   UpdateRow(var item, ExternalCallAvailability ec);

3. È possibile modificare il nome della funzione in qualche modo in modo che rifletta meglio il significato del boolparametro. Non molto sicuro ma forse:

   UpdateRowWithExternalCall(var item, bool externalCall)

Un'altra opzione che non ho ancora letto qui è: utilizzare un IDE moderno.

Ad esempio IntelliJ IDEA stampa il nome della variabile delle variabili nel metodo che stai chiamando se stai passando un valore letterale come trueo nullo username + “@company.com. Questo viene fatto con un carattere piccolo, quindi non occupa troppo spazio sullo schermo e sembra molto diverso dal codice reale.

Non sto ancora dicendo che sia una buona idea lanciare booleani ovunque. L'argomento secondo cui leggi il codice molto più spesso di quanto scrivi è spesso molto forte, ma per questo caso particolare dipende fortemente dalla tecnologia che tu (e i tuoi colleghi!) Utilizzate per supportare il vostro lavoro. Con un IDE è molto meno un problema che ad esempio con vim.

Esempio modificato di parte della mia configurazione di prova:

2 giorni e nessuno ha menzionato il polimorfismo?

target.UpdateRow(item);

Quando sono un cliente che desidera aggiornare una riga con un elemento non voglio pensare al nome del database, all'URL del micro-servizio, al protocollo utilizzato per comunicare o alla presenza o meno di una chiamata esterna dovrà essere usato per realizzarlo. Smetti di spingere questi dettagli su di me. Prendi il mio oggetto e vai ad aggiornare una riga già da qualche parte.

Fallo e diventa parte del problema di costruzione. Questo può essere risolto in molti modi. Eccone uno:

Target xyzTargetFactory(TargetBuilder targetBuilder) {
    return targetBuilder
        .connectionString("some connection string")
        .table("table_name")
        .external()
        .build()
    ; 
}

Se lo stai guardando e pensando "Ma la mia lingua ha chiamato argomenti, non ne ho bisogno". Bene, ottimo, vai ad usarli. Basta tenere fuori questa assurdità dal client chiamante che non dovrebbe nemmeno sapere con cosa sta parlando.

Va notato che questo è più di un problema semantico. È anche un problema di progettazione. Passa un booleano e sei costretto a usare la ramificazione per affrontarlo. Non molto orientato agli oggetti. Devono passare due o più booleani? Desideri che la tua lingua abbia ricevuto più spedizioni? Scopri cosa possono fare le raccolte quando le annidate. La corretta struttura dei dati può semplificarti la vita.

Se puoi modificare la updateRowfunzione, forse puoi rifattarla in due funzioni. Dato che la funzione accetta un parametro booleano, sospetto che assomigli a questo:

function updateRow(var item, bool externalCall) {
  Database.update(item);

  if (externalCall) {
    Service.call();
  }
}

Questo può essere un po 'un odore di codice. La funzione potrebbe avere un comportamento notevolmente diverso a seconda dell'impostazione della externalCallvariabile, nel qual caso ha due diverse responsabilità. Rifattorizzarlo in due funzioni che hanno una sola responsabilità può migliorare la leggibilità:

function updateRowAndService(var item) {
  updateRow(item);
  Service.call();
}

function updateRow(var item) {
  Database.update(item);
}

Ora, ovunque tu chiami queste funzioni, puoi capire a colpo d'occhio se viene chiamato il servizio esterno.

Questo non è sempre il caso, ovviamente. È situazionale e una questione di gusti. Rifattorizzare una funzione che prende un parametro booleano in due funzioni di solito vale la pena considerare, ma non è sempre la scelta migliore.

Se UpdateRow si trova in una base di codice controllata, prenderei in considerazione il modello di strategia:

public delegate void Request(string query);    
public void UpdateRow(Item item, Request request);

Where Request rappresenta una specie di DAO (un callback in casi banali).

Caso vero:

UpdateRow(item, query =>  queryDatabase(query) ); // perform remote call

Caso falso:

UpdateRow(item, query => readLocalCache(query) ); // skip remote call

Di solito, l'implementazione dell'endpoint sarebbe configurata su un livello superiore di astrazione e la userei qui. Come utile effetto collaterale gratuito, questo mi dà la possibilità di implementare un altro modo per accedere ai dati remoti, senza alcuna modifica al codice:

UpdateRow(item, query => {
  var data = readLocalCache(query);
  if (data == null) {
    data = queryDatabase(query);
  }
  return data;
} );

In generale, tale inversione di controllo garantisce un accoppiamento inferiore tra la memorizzazione dei dati e il modello.