La progettazione per contratto implica un output corretto?

Question

La progettazione per contratto implica un output corretto?

#1 da (0 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

1

Design by Contract dice, in termini di funzione, parlando: "mi dai tutti i parametri corretti e ti darò esattamente questo tipo di dati" ... in sostanza.

Quindi, dato che, dovrei usare le risorse per controllare l'output? Dovrei controllare le proprietà che la funzione non garantisce che la sua uscita possieda, ma le proprietà che garantisce la funzione non devono essere controllate, giusto?

Ecco un esempio:

class Transition_Manager {
    string str = generate_non_null_string();
    process_using_a_function_that_can't_handle_null_strings( str );
}

design-by-contract

posta user2738698 04.04.2014 - 20:36

fonte

4 risposte

0

se raccogli informazioni da fonti non attendibili (rete, utente), dovresti controllare tutto

che diceva che detta ricerca binaria non sarebbe mai stata in grado di funzionare senza l'ipotesi (non controllata) della matrice ordinata. se hai controllato l'ordinamento, allora potresti anche fare una ricerca lineare.

la cosa più importante è riuscire a fallire con garbo se si ottengono dati errati, il debugging è molto più semplice quando c'è una bella eccezione e il relativo log da guardare.

risposta data 04.04.2014 - 20:42

fonte

0

Considera di convalidare l'output della tua funzione prima del runtime .

Puoi farlo scrivendo unit test che validano l'output della tua funzione per tutti gli input validi noti (o forse solo un sottoinsieme rappresentativo di input validi se l'intero set è troppo grande).

Ciò compensa il costo della convalida dei dati dall'applicazione al processo di sviluppo.

Funziona particolarmente bene se hai qualcosa come un server di integrazione continua configurato per eseguire automaticamente i tuoi test.

risposta data 04.04.2014 - 20:43

fonte

-1

Come scrittore API, devi verificare che i parametri in entrata soddisfino i tuoi criteri di elaborazione prima di procedere, indipendentemente da chi pensi di chiamarti.

Come consumatore dell'API, dovresti verificare che i risultati soddisfino le tue esigenze di elaborazione indipendentemente da quanto pensi che sia sicura l'API.

Durante la scrittura del codice, la fiducia è sopravvalutata.

risposta data 04.04.2014 - 23:05

fonte

Leggi altre domande sui tag design-by-contract

Trova antenato comune Ricerca dal vivo / filtro durante la digitazione nell'approccio client

score 0 · Accepted Answer

La metodologia Design-by-Contract rende evidente la separazione delle responsabilità:

un cliente deve soddisfare una precondizione di un fornitore
un fornitore deve soddisfare la sua postcondizione non appena viene soddisfatta la condizione preliminare

Come risultato di questa politica

se la precondizione è violata, è un errore del client (il client è "colpevole", è un bug nel codice del client)
se viene violata la post-condizione, è un errore nel fornitore (il fornitore è "colpevole", è un bug nel codice del fornitore)

Ecco perché è chiamato "contratto" - è un contratto / un accordo tra due parti - il cliente e il fornitore - per soddisfare queste condizioni.

Dal punto di vista del cliente, deve soddisfare la condizione preliminare, ma poi può contare sulla post-condizione che è un obbligo del fornitore. Non è necessario ricontrollare l'output.

Nella vita reale spetta agli autori del codice fornitore come assicurarsi che l'output sia sempre corretto non appena l'input è corretto, sia che si tratti di debug, test, verifica, revisione del codice o altro. Negli ambienti che supportano DbC in modo nativo, è possibile eseguire il monitoraggio run-time delle precondizioni e delle post-condizioni durante l'esecuzione del programma. La violazione del contratto punta immediatamente alla parte che ha problemi.