[ContractClass] et [ContractClassFor] permettent, par injection, de placer des contrats de code sur des interfaces, et qu’on retrouvera sur les classes d’implémentation.
[ContractInvariantMethod] et Contract.Invariant() pour les invariances de valeurs.
Pour hériter des contraintes depuis une interface, on implémente une classe sur cette interface et qui va porter les contraintes d’invariance, de pré- ou de post-condition, et on la marque avec [ContractClassFor], et on va mettre l’attribut [ContractClass(typeof(laClasseHeritantLInterface)] sur l’interface.
Vérification des contrats à la compilation dans la version Premium ou Ultimate, ou avec l’utilitaire cccheck. Contrat.Assume permet d’informer le vérificateur qu’une valeur a été validée par un autre moyen que le code (exemple : le contrôle WPF l’envoyant), et que c’est normal que le code ne prouve pas lui-même le respect de la contrainte dans cet enchaînement particulier de fonctions.
Contract.EndContractBlock() permet de délimiter la fin d’un code directement écrit en C# juste après la déclaration de fonction, et qui du coup sera pris en compte comme si c’était du CodeContract, y compris en terme d’héritage, etc.
Un outil permet d’avoir une assembly sans les règles, et une assembly séparée avec les contracs. Typiquement à utiliser après le staging, et pour avoir les performances maxi en production, par suppression des règles.
C’est le Code Contract Rewriter qui injecte les règles dans la dll intégrateur. Call-site requires checking est l’option des propriétés CodeContract qui permet d’activer ce comportement. Avant d’utiliser, il faudra bien vérifier que le problème de signature par nom fort a bien été pris en compte.
Common Compiler Infrastructure = l’API de base utilisée par FXCop, SandCastle, etc. pour parcourir le code compilé.
