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);
}
}
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'. –