La programmation par contrat c'est bon, mangez en.
Ceci dit, dans des langages objet, leur utilisation en cas d'héritage + polymorphisme devient obscure. La syntaxe de Eiffel en témoigne (require else et consort). Pour autant, je ne vois pas en quoi c'est plus tendu pour les post-conditions et les invariants de boucle. Autant j'ai un problème avec les invariants de classe (on fait comment quand une instance de la classe a un invariant cassé puisqu'on ne peux plus invoquer de méthodes de cette instance sans rompre le contrat de l'invariant), autant je n'en ai pas plus avec les post-conditions (contrat de sortie) et les invariants de boucle (contrat local, a priori pour le debug?) qu'avec les pré-conditions (contrat de sortie).
[^] # Re: Ma réponse :
Posté par left . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 2.
Ceci dit, dans des langages objet, leur utilisation en cas d'héritage + polymorphisme devient obscure. La syntaxe de Eiffel en témoigne (require else et consort). Pour autant, je ne vois pas en quoi c'est plus tendu pour les post-conditions et les invariants de boucle. Autant j'ai un problème avec les invariants de classe (on fait comment quand une instance de la classe a un invariant cassé puisqu'on ne peux plus invoquer de méthodes de cette instance sans rompre le contrat de l'invariant), autant je n'en ai pas plus avec les post-conditions (contrat de sortie) et les invariants de boucle (contrat local, a priori pour le debug?) qu'avec les pré-conditions (contrat de sortie).