Se ho un metodo che necessita di verifica per poter procedere, lo chiamo all'interno del metodo o prima? [duplicare]

2

Questo mi ha infastidito. Questo è più un problema pragmatico che tecnico. Immagina di avere un metodo SaveOrderChanges che, come suggerisce il nome, salverà le modifiche degli ordini quando l'utente invia l'ordine modificato.

Tuttavia, prima di salvare l'ordine, devo verificare se l'ordine inviato è effettivamente dell'utente attuale, quindi procedo a fare una semplice verifica nel DB. Ho un metodo speciale che funziona con questa situazione che ho chiamato "VerifyOrder ()".

La vera domanda è se il metodo SaveOrderChanges () dovrebbe includere la chiamata a quel metodo, o l'altro metodo dovrebbe essere chiamato prima che SaveOrderChanges () sia chiamato

Immagina di avere qualche metodo come questo:

Lo faccio in questo modo:

public bool SaveOrderChanges(Order order)
{
  VerifyOrder(order); //Verify that the order is from the actual user
  //Some Code Logic in here
}

O come questo:

if(VerifyOrder(order))
{
  SaveOrderChanges(order); 
}
    
posta Jose A 27.05.2015 - 21:59
fonte

4 risposte

2

Devi scegliere quest'ultimo.

Nel prendere la mia decisione, ho deciso di guardare questo dal punto di vista del programmatore di manutenzione. Ecco come vedrei ogni caso:

  1. VerifyOrder(order) è all'interno di SaveOrderChanges(Order order) , quindi la verifica è parte di ciò che SaveOrderChanges() fa. È necessario verificare per poter salvare.

  2. VerifyOrder(order) deve essere valido per eseguire SaveOrderChanges(Order order) , quindi la verifica non fa parte di ciò che SaveOrderChanges(Order order) fa. Qualsiasi modifica a SaveOrderChanges() non deve includere VerifyOrder() .

È tutta una questione di semantica. Inserendo la verifica all'interno della funzione, stai dicendo che la funzione esegue la verifica. Se hai bisogno di una verifica preventiva, assicurati che non faccia parte della funzione per mantenere la separazione dei dubbi.

Inoltre, consideriamo il caso in cui vai con (1) e la verifica fallisce. L'esecuzione uscirà dalla funzione di verifica e sarà ancora all'interno di SaveOrderChanges() (come viene scritto il tuo codice). Questo è l'elemosina di bug che non vuoi.

    
risposta data 27.05.2015 - 22:06
fonte
4

Il primo; SaveOrderChanges dovrebbe chiamare VerifyOrder . Altrimenti, un futuro codificatore chiamerà SaveOrderChanges senza chiamare VerifyOrder . Un'alternativa che impedisce ancora un simile errore è di chiamare VerifyOrder al di fuori di SaveOrderChanges , ma entrambi i metodi devono essere privati.

Suppongo che SaveOrderChanges abbia una precondizione che VerifyOrder avrà successo; viene chiamato per rilevare i bug piuttosto che come parte dell'elaborazione dell'ordine. Secondo questa ipotesi, è (probabilmente) la responsabilità del chiamante di chiamare solo SaveOrderChanges su ordini validi; idealmente una chiamata fallita a VerifyOrder indica un bug nel codice del chiamante.

    
risposta data 27.05.2015 - 22:08
fonte
0

Se puoi davvero rovinare lo stato dei tuoi dati salvando un ordine non valido allora qualcosa deve fare la verifica. O il datastore deve saltare in aria e rifiutare la transazione, o alcuni codici devono verificare la validità dell'ordine. Non vorrei esporre un'API pubblica che consente di salvare un ordine se può causare il danneggiamento dei dati.

    
risposta data 27.05.2015 - 22:11
fonte
0

Se il calcolo della verifica non è costoso, vorrei verificare prima di chiamare il metodo e affermare che la verifica passa all'interno del metodo. Ciò garantisce che gli errori di programmazione saranno presto individuati e consente ai chiamanti di gestire il caso in caso contrario.

    
risposta data 27.05.2015 - 22:12
fonte

Leggi altre domande sui tag