En théorie oui. En pratique, c'est le genre de truc que les programmeurs detestent parce que c'est extrèmement chiant à maintenir. Trop lourd, trop contraignant. Chaque fois que tu changes le code d'une méthode, il faut changer le contrat aussi.
Normalement si tes contrats (preconditions et postconditions) sont bien écrit, ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs (en effet, le mieux est d'écrire tes contrats à partir des spécif (diagrammes UML), et d'ensuite coder les méthodes). Je te l'accorde, c'est assez idéaliste comme point de vue.
Exemple: tu écrit une classe Set (tableau ne pouvant pas contenir de doublons, ex: (8,2,3,6)=>OK, (2,3,2,6)=>KO) avec une méthode add (pour ajouter un éléments), tu auras des contrats du type :
signature:
public void add (int member // élément à ajouter )
précondition:
@pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans
postcondition:
@post has(member) == true // l'élément que tu as ajouté est bien dans ton Set à la fin de ta méthode
@post has(member)@pre implies size() == size()@pre // Si l'élément était déjà dans ton Set alors la taille de celui-ci doit être le même à la fin de ta méthode
@post ! has(member)@pre implies size() == size()@pre + 1 // Si l'élément n'était pas dans ton Set alors celui-ci doit avoir un élément de plus à la fin de ta méthode.
has() et size() étant une méthode de la classe Set
Ca parrait assez lourd à mettre en place, mais ça permet de vraiment spécifier comment fonctionne ta classe, du coup tu fais moins de doc, et il y a moins d'ambiguité sur la façon de mettre le code en place. Un des avantages est que les postconditions peuvent servir d'oracle durant tes tests. De plus, il existe de bon bouquin d'initiation à la programmation contractuelle (par exemple :Design by Contract, by Example de Richard Mitchell and Jim McKim)
Etant moi même un flemmard de la programmation (j'aime pas mettre des commentaires et vérifier pendant trois plombes mon code), j'ai vite compris l'intéret de cette approche.
Je t'accorde qu'il n'est pas facile d'imposer une telle approche dans une équipe, mais c'est un choix de méthode de développement (comme par exemple pour l'eXtreme Programming). Il y a des avantages et des inconvénient.
J'essayerais de faire un condensé (ou d'en trouver un) sur cette approche si j'ai le temps.
[^] # Re: OCM 2002
Posté par pifou . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 10.
Normalement si tes contrats (preconditions et postconditions) sont bien écrit, ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs (en effet, le mieux est d'écrire tes contrats à partir des spécif (diagrammes UML), et d'ensuite coder les méthodes). Je te l'accorde, c'est assez idéaliste comme point de vue.
Exemple: tu écrit une classe Set (tableau ne pouvant pas contenir de doublons, ex: (8,2,3,6)=>OK, (2,3,2,6)=>KO) avec une méthode add (pour ajouter un éléments), tu auras des contrats du type :
signature:
public void add (int member // élément à ajouter )
précondition:
@pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans
postcondition:
@post has(member) == true // l'élément que tu as ajouté est bien dans ton Set à la fin de ta méthode
@post has(member)@pre implies size() == size()@pre // Si l'élément était déjà dans ton Set alors la taille de celui-ci doit être le même à la fin de ta méthode
@post ! has(member)@pre implies size() == size()@pre + 1 // Si l'élément n'était pas dans ton Set alors celui-ci doit avoir un élément de plus à la fin de ta méthode.
has() et size() étant une méthode de la classe Set
Ca parrait assez lourd à mettre en place, mais ça permet de vraiment spécifier comment fonctionne ta classe, du coup tu fais moins de doc, et il y a moins d'ambiguité sur la façon de mettre le code en place. Un des avantages est que les postconditions peuvent servir d'oracle durant tes tests. De plus, il existe de bon bouquin d'initiation à la programmation contractuelle (par exemple :Design by Contract, by Example de Richard Mitchell and Jim McKim)
Etant moi même un flemmard de la programmation (j'aime pas mettre des commentaires et vérifier pendant trois plombes mon code), j'ai vite compris l'intéret de cette approche.
Je t'accorde qu'il n'est pas facile d'imposer une telle approche dans une équipe, mais c'est un choix de méthode de développement (comme par exemple pour l'eXtreme Programming). Il y a des avantages et des inconvénient.
J'essayerais de faire un condensé (ou d'en trouver un) sur cette approche si j'ai le temps.
-1 car c'est vraiment pas le sujet de la news