Un modulo è autorizzato a formulare assunzioni implicite?

3

Uso .Net e C #.

Ho il seguente codice in qualche modulo:

DateTime validFrom = Convert.ToDateTime(validFromTxt.Text);

Questo rende (a mio avviso) le assunzioni implicite

  • che c'è testo in validFromTxt.Text
  • che è possibile convertire questo in tipo DateTime.

La mia domanda è, può il modulo formulare queste assunzioni implicite (dovute alla "conoscenza" del contesto della pagina) o sarebbe meglio controllarle prima del comando?

    
posta AGuyCalledGerald 05.08.2011 - 13:39
fonte

4 risposte

6

A mio parere, i moduli sono autorizzati a formulare ipotesi se sono esplicitamente documentati nella documentazione del modulo / descrizione del metodo.

Questo è un concetto importante di Design per contratto . Definisci i contratti tra i diversi moduli per stabilire la responsabilità di ciascuno di essi.

Nel tuo caso, potresti decidere che tutte le convalide sono responsabilità del tuo modulo. In tal caso tutti gli altri moduli possono invocare i tuoi senza un controllo precedente. Ma anche la notte decidi che il tuo modulo è molto semplice e supponi che la data debba essere verificata in un altro modulo, nel qual caso puoi fare l'ipotesi che la data sia valida. Tuttavia, è necessario specificare nella documentazione che il comportamento imprevisto (eccezione, risultato errato) potrebbe verificarsi se la data non è valida.

Alla fine, si tratta solo di distribuire le responsabilità nei moduli della domanda e garantire che tutti i moduli rispettino i loro contratti.

    
risposta data 05.08.2011 - 14:25
fonte
5

Se non puoi garantire che il tuo contributo è valido, devi verificarlo. Come lo fai dipende dal tuo scenario. Dato che è altamente improbabile che tu abbia sempre un input valido - abbiamo a che fare con gli umani, dopo tutto - quindi è necessaria una sorta di convalida.

Se sai che la maggior parte delle volte l'input sta per esistere ed essere valido, usare la gestione delle eccezioni attorno alla conversione è probabilmente la strada da percorrere. Ciò significa che il normale funzionamento del codice sarà il più veloce possibile.

Se sai che molte volte l'input non è valido, probabilmente dovresti controllarlo prima di provare a convertirlo. Ciò significa che mentre si verifica un sovraccarico nell'elaborare l'input corretto, anche l'input non corretto viene gestito in modo efficiente.

    
risposta data 05.08.2011 - 13:46
fonte
2

Nessuna ipotesi dovrebbe essere fatta. L'input è sotto forma di una casella di testo che è solo una stringa. Leggere qualsiasi valore dalla casella di testo non dovrebbe assumere nulla. Se l'unput deve essere una data, è necessaria una routine di validazione per verificare che la stringa sia realmente una data prima di passarla ulteriormente.

Come raccomandazione, suggerisco di sostituire la casella di testo con un DateTimePicker o un altro controllo di data e ora. Ciò consentirà agli utenti di scegliere comunque una data, ma il valore non è una stringa ma un oggetto .Net DateTime. Quindi non ci sono ipotesi in quanto il controllo ha i dati nel formato richiesto dall'inizio.

    
risposta data 05.08.2011 - 17:30
fonte
0

Poiché esiste un oggetto validFromTxt puoi provare a convertire il testo fino alla data, ma non dovresti mai presumere che i dati dell'utente siano validi. Prova a convertire e cattura l'eccezione se si verifica.

    
risposta data 05.08.2011 - 18:57
fonte

Leggi altre domande sui tag