Je trouve également que ce langage très agréable : tout est propre, bien pensé. La programmation par contrat, pour ceux qui ne connaissent pas consiste à considérer que l'utilisation de chaque méthode est soumise à un contrat : si l'utilisateur de la méthode respecte certaines contraintes (le préconditions, ou require), alors, moi, concepteur de la méthode, je lui garantis un certain résultat (les post-conditions, ou ensure). Exemple de code dans la classe matrice :
inverse : MATRICE is -- nom_de_fonction : type_renvoyé
-- Renvoie l'inverse la matrice -- commentaire require -- zone preconditions
is_inversible -- fonction booléenne qui teste si la matrice est inversible do -- begin ou {
... -- code : peu timporte, ce qui compte, c'est le contrat ensure -- zone postconditions
Current x Result = Identite -- Current = object courant; x = opérateur infixe de multiplication de matrices;
-- Result = objet résultat dans le cas d'une fonction
-- Identite = Object défini une seule fois comme étant la matrice identité end -- end ou }
Comme vous le voyez, ces contraintes sont écrites dans le langages lui-même, et, plus fort, ces contraintes peuvent être vérifiées à l'exécution ! Dès qu'une pré ou postcondition est violée, le programme s'arrête et signale la violation. Les bogues sont donc détectés le plus tôt possible.
Il existe aussi les invariants qui permettent de spécifier des contraintes toujours vraies. Ex : dans la classe COMPLEXE :
invariant
Re = module * cos(argument) and Im = modules * sin(argument).
Au département d'informatique de l'université Paris 13 (pour l'enseignement donc), nous avons choisi de nous inspirer de la méthode Eiffel pour les cours de programmation objet. Malheuresement, la "mode" et les contraintes horaires nous obligent à voir la pratique en Java. Nous utilisons cependant des extensions à Java qui permettent d'inclure des pré- et post-condition et invariants dans les commentaires sous forme de tags, et de les vérifier à l'exécution. Il existe plusieurs solutions, avec chacune ses avantages, au niveau de la précompilation et de la gestion de la documentation :
jContract
iContract
Jass
Jcontract
JMSAssert
jassert
Handshake
Java Modeling Language (JML) - un peu différent, mais même esprit
[^] # Re: Quelques "coquilles"
Posté par Guillaume Vauvert . En réponse à la dépêche Sortie de Hercule la version 2 du compilateur SmartEiffel. Évalué à 8.
Comme vous le voyez, ces contraintes sont écrites dans le langages lui-même, et, plus fort, ces contraintes peuvent être vérifiées à l'exécution ! Dès qu'une pré ou postcondition est violée, le programme s'arrête et signale la violation. Les bogues sont donc détectés le plus tôt possible.
Il existe aussi les invariants qui permettent de spécifier des contraintes toujours vraies. Ex : dans la classe COMPLEXE :
Au département d'informatique de l'université Paris 13 (pour l'enseignement donc), nous avons choisi de nous inspirer de la méthode Eiffel pour les cours de programmation objet. Malheuresement, la "mode" et les contraintes horaires nous obligent à voir la pratique en Java. Nous utilisons cependant des extensions à Java qui permettent d'inclure des pré- et post-condition et invariants dans les commentaires sous forme de tags, et de les vérifier à l'exécution. Il existe plusieurs solutions, avec chacune ses avantages, au niveau de la précompilation et de la gestion de la documentation :
jContract
iContract
Jass
Jcontract
JMSAssert
jassert
Handshake
Java Modeling Language (JML) - un peu différent, mais même esprit