2014-04-23 15 views
7

Perché dovrei utilizzare contratti di codice comecontratti Codice benefici

Contract.Requires<ArgumentNullException>(x != null, "x"); 

al posto del buon vecchio

if (x!=null){} 
else throw... 

Ci sono altri vantaggi, ad eccezione di concisione?

risposta

10

Secondo il MSDN:

I vantaggi di contratti di codici sono i seguenti:

  • Migliorata test: contratti codice prevedono la verifica statica del contratto, il controllo di esecuzione, e la generazione di documentazione.
  • Strumenti di test automatici: è possibile utilizzare i contratti di codice per generare test unitari più significativi filtrando argomenti di test privi di significato che non soddisfano le condizioni preliminari.
  • Verifica statica: il controllore statico può decidere se vi sono violazioni del contratto senza eseguire il programma. Controlla i contratti impliciti, come dereferenze nulle e limiti di array, e contratti espliciti.
  • Documentazione di riferimento: il generatore di documentazione aumenta i file di documentazione XML esistenti con le informazioni del contratto. Ci sono anche fogli di stile che possono essere usati con Sandcastle in modo che le pagine di documentazione generate abbiano sezioni di contratto.

vostro chilometraggio può variare quali di questi punti sono importanti o meno. Ho trovato la terza e la quarta (verifica statica e documentazione) particolarmente interessanti.

In altre parole, è un modo più strutturato di descrivere i contratti (anziché i costrutti come if (x!=null){}) che gli strumenti aggiuntivi sono in grado di comprendere.

+0

Personalmente mi piace punto 3 di più, si ora ottieni errori del compilatore su cose che sarebbero state errori di run-time come 'NullRefrenceExcption' o' Arg umentOutOfRangeException'. –

5

Oltre allo zucchero sintattico, Contratti di codice è lo strumento di Microsoft per il paradigma "Design by Contract". http://en.wikipedia.org/wiki/Design_by_contract

Fondamentalmente un modo diverso di pensare quando si progettano le lezioni e le operazioni. Dall'esperienza, DbC funziona molto bene con Test Driven Development, definendo fondamentalmente contratti e test di scrittura per questo prima di scrivere qualsiasi logica di business.

Dietro le quinte, contratto Contratto genera codice simile al tuo buon vecchio codice in fase di compilazione, quindi il codice IL contiene tutti i controlli.

Ad esempio, la classe

public class Scheduler 
{ 
    public bool ScheduleTask(string taskname, DateTime startTime, DateTime endTime) 
    { 
     Contract.Requires(!string.IsNullOrWhiteSpace(taskname)); 
     Contract.Requires(startTime != null); 
     Contract.Requires(endTime != null); 
     return true; 
    } 
} 

si tradurrà in qualcosa di simile

public bool ScheduleTask(string taskname, DateTime startTime, DateTime endTime) 
{ 
    __ContractsRuntime.Requires(!string.IsNullOrWhiteSpace(taskname), null, "!string.IsNullOrWhiteSpace(taskname)"); 
    __ContractsRuntime.Requires(true, null, "startTime != null"); 
    __ContractsRuntime.Requires(true, null, "endTime != null"); 
    return true; 
} 

dove _ContractsRuntime.Requests assomigliano seguente

internal static void Requires(bool condition, string msg, string conditionTxt) 
{ 
    if (!condition) 
    { 
     __ContractsRuntime.ReportFailure(ContractFailureKind.Precondition, msg, conditionTxt, null); 
    } 
} 
Problemi correlati