Le 4 Feb 2002 Jerome Moliere a �crit : > > il est clair, t'as le meme resultat, en ecrivant moins de code, donc > code plus compact, de plus ce code peut etre genere par un AGL puisque > du coup tu integres dans ton modele les invariants... au lieu de le > camoufler dans l'implementation!!! de plus tu oublies le comportement > lors d'heritage ou tu es oblige de dupliquer tes tests, alors que la > DBC > te garantit un comportement reellement objet... >
Pourrais-tu expliquer un peu, avec moins de code sp�cifique informaticien ? Pour ma part je suis un peu r�serv� sur la programmation par contrat, dans l'�tat actuel de ma reflexion, s'entend. Telle que je comprends cette technique, il s'agit de placer des contr�les, au d�part et � la fin de chaque m�thode, de fa�on � v�rifier que l'objet et les param�tres de la m�thode sont valides. Il y a donc deux �tapes : 1) d�couvrir comment exprimer la validit� d'un objet et des param�tres, 2) contr�ler cette validit�. J'approuve l'�tape 1), mais pas l'�tape 2). Pour moi, la bonne �tape 2) serait : "Qu'est ce que je peux faire pour que de toutes fa�ons ni mon objet ni mes param�tres ne puissent �tre invalides ?" Donc, pour r�pondre � l'�tape 1), je travaille sur le design de l'objet et de son environnement, non sur ses contr�les internes. Bien s�r, c'est l'id�al. Comme en informatique on a toujours besoin de mettre de l'eau dans le vin des bons principes, la programmation par contrat est la bienvenue, mais uniquement pour cacher les approximations du design, et il vaut mieux le faire. Et de toutes fa�ons je suis � un moment ou � un autre oblig� de faire des contr�les internes, c'est vrai. Il y a une deuxi�me raison pour laquelle je suis r�serv� avec les contrats. Normalement, une fois un objet cr��, l'ext�rieur n'est pas cens� savoir dans quel �tat il est, et est donc susceptible d'appeler les m�thodes de cet objet dans n'importe quel ordre. Donc, si je contr�le l'entr�e de l'une quelquonque de ces m�thodes, je contr�le quoi ? Je ne vais pas contr�ler qu'il a appel� les m�thodes dans le bonne ordre, ce serait une erreur de design : je dois me d�brouiller quelque soit l'ordre d'appel (id�al). Donc je ne peux v�rifier qu'un �tat g�n�ral de l'objet, quasiment le m�me pour toutes les m�thodes. Les invariants ne peuvent exister que sur des donn�es constantes sur l'ensemble des m�thodes de l'objet, et non pas d'une seule. Finalement, j'en arrive � penser que, au lieu que le contr�le se fasse au niveau de chaque m�thode comme dans la programmation par contrat, le contr�le devrait se faire au niveau des d�clarations ; c'est au niveau des d�clarations qu'il faut faire porter l'effort d'expression, non au niveau de l'entr�e et de la sortie des m�thodes. Pour reprendre les deux exemples cit�s (bancaire et Toto) voici ma fa�on de penser. Si j'ai comme pr�condition : @pre solde-montant>decouvert_autorise C'est une condition g�n�rale de l'objet (j'y connais rien dans le m�tier bancaire, notez). Il exprime une relation entre solde-montant et decouvert_autorise, cela est un indice qu'il existe une sorte de classe qui lie les deux. J'aurais donc tendance � cr�er une classe sp�ciale type entier qui ne descend jamais en dessous du solde autoris�, et ta classe bancaire ne manipule que des objets de cette classe l�. Le contr�le se ferait donc par un design plus expressif, par une classe manipul�e partout ; il devient inutile d'en mettre � l'entr�e et � la sortie de chaque m�thode. Si je prends : @pre aTiti != null J'avoue que je comprends pas l'int�r�t. De toutes fa�ons quand je fait aTiti.getToto() la JVM contr�le que aTiti est diff�rent de null ; si je veux rajouter un controle, c'est parce que le traitement par d�faut de la JVM ne me satisfait pas ; hors, l�, je ne vois aucun ajout de comportement particulier en cas d'echec du controle ? Bref, selon mes petites th�ories, plus un langage est riche au niveau des possibilit�s d�claratives, plus la programmation par contrat est inutile. Et l'inverse c'est l'inverse. Pour des langages comme Basic de grand p�re, la programmation par contrat est absolument utile. Pour Java, il me semble qu'il y a mieux � gagner en r�fl�chissant plus aux bonnes pratiques d�claratives, et en les outillant. A+. -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
