voila pour rien caché j'ai interro demain en prog et j'ai du mal a capter les post et pres condition. est ce kelk'un aurai la grande bonté de m'expliker un peu comment ça marche ce soir. svp. je suis un peu ds la merde.  
ou a la rigueur me dire ou je peu touver ça d'expliker en français. merci

ban

Si tu veux de l'aide, la moindre des choses ça serait de détailler plus ce que tu ne comprends pas; je pensais connaitre assez bien le java mais je ne comprends pas de quoi tu parles.

moi aussi, je veux bien essayer de répondre à ta question, mais là ...

 
Je le connais, il est sympa... Soyez cool Il est nouveau ici.
 
Au fait, Lunatik, une règle élémentaire chez nous : les "ça urge !!!" ça passe pas ici.  

les préconditions, c'est le présupposé sur tes variables par exemple (qu elles soient pas NULL, que a>b, que sais je encore)
les posts, c est la même chose mais après ta fonction, tu dis ce qu elle est censée faire

ha ouais d'accord ...
elle revient de loin celle-là

en fait, ça concerne les réseaux de pétri et Cie, ce genre de considération ...
ou encore les GDU (Graphe Def-Use) ...
que des trucs chiants quoi  

 
et moi qui cherchais un truc spécifique java  
 
 
n'empeche que ça manque toujours gravement de détails, ya pas marqué irma là

dsl pour le ça urge. merci hermes de ta tolerance( les autre aussi d'ailleur, parfois qd on ecrit un post on reflechie pas assez).  en faite ce ke je capte pas c un: deja comment on les declares si vs aviez un exemple se serais super cool en faite
j'ai du mal a voir comment c foutu
 
pour les post condtions ça doit un truc comme ça
 

 
je voudrai savoir k'est ce ki se passe qd ma post condition est fausse.
 
pour les pré conditions on utilise les assertion c ça?
 
on ecrit ça?

 
avant la methode?
 
a la fin de la methode on fait  
 

 
on doit mettre obligatoirement des throw avec les post et prés conditions?
 
k'est ce ki ce passe qd truc < 0?
 
voila deja ça ki reste assez flou. je vois un peu le truc mais je le saisi pas enkor.

LunatiK3: question pour voir si tu as compris :  
 
On peut mettre une précondition sur un constructeur ?

a vrai dire j'en ai aucune idées, je voix pas ce ki empecherai. et justement j'ai pas capter alors la je te repond un peu au feeling.

Les pre et post conditions comme tu les apelles sont parfois apellées assertions; dans le même genre on peut aussi raisonner avec la notion d'invariant dans un algorithme.
 
Ce sont des conditions qui doivent être absolument respectées à un moment fixé de n'importe quelle itération lors du déroulement d'un algorithme.
 
Il n'y a pas grand chose à comprendre en fait; les pre conditions d'une méthode forment l'ensemble des assertions nécéssaires (non forcément suffisantes) à son bon déroulement. Les post conditions forment l'ensemble des assertions nécéssairement vérifiées à la sortie de ta méthode.
 
Voila voila rien de bien intéréssant

Normalement, les pré conditions sont les conditions à remplir pour que ta méthode marche correctement, théoriquement tu n'es donc pas sensé les vérifier, mais bon c'est comme tu le sens et ca dépend des cas.
 
Les post conditions expliquent ce qui a été modifié par la méthode:
changement de l'état d'un objet, modification de telle ou telle variable, ca dépend un peu de la méthode.
 
En tout cas, c'est comme ca que je fais mes pré-post moi.

mais alors si l'algorythme se trouve en contradiction avec les assertion k'est ce ki ce passe?
interressant ou pas c pas la question, je vais peu etre tomber la dessu en interro demain, alors..
 
les pre condition je pense en avoir compris l'interet. mais les post c plus vague. pour les post, si je comprend: on pose des assert et on dit ke tel truc doit etre comme ça et tel autre comme cei. du genre
 

 
le message il est balancer qd l'asssertion n'est pas respecter c ça?
 
les post et pres condition agissent sur l'algorythme ou c juste pour expliker au programmeur  les conditions ?

Bon déjà fais moi playzyr, écris donc algorithme sans le 'y', ca fera moins désordre sur ta copie de demain    
 
Pour revenir à tes moutons, un invariant d'algorithme doit forcément être vérifié par définition. S'il existe au moins un cas ou il est mis en défaut cela contredit se définition.
 
 
Les preconditions définissent quelle situation initiale est requise pour le bon déroulement d'un algo.
Les "supposés" invariants permettent de vérifier que l'algo se déroule bien à chaque itération.
Les postconditions forment les domaines du possible après le déroulemnt de l'algo.
 
Bien réfléchir sur les pre/post conditions et invariants d'un algorithme peut permettre de démontrer qu'il fonctionne(mais c'est pas facile pour les nains formaticiens  ) .

dc les post et prés condition n'agissent pas sur le prog en lui meme. c ça?
pour ecrire un pre-condition on fait
 

 
c ça ?
 il ya pas d'autre truc a mettre?
 

 
 
Oui, tu peux comprendre ça comme les prérequis.
 
En amont de l'apel de ta méthode, les pre conditions peuvent être vérifiées par le programme lui même dans le cas ou ce dernier doit être mongol-proof.

ok merci. j'espere ke j'ai bien capter le truc. je prie pour mon interro demain. merci beaucoup pour votre aide a tous. a+

 
Ca manque surtout de culture => "Conception et programmation orientées Objet" B. Meyer.
 

 
Au hazard (pas tout à fait) : je mets une beigne à 80% des cas si "not null" n'est pas vérifié pour chaque argument du constructeur et à 30-40% des cas si la longueur des chaines passées n'est pas vérifiée comme étant > 0 ?
 
C'est vraiment passé en mot clef de javadoc @pre et @post ? je peux aussi faire @invariant et ça va générer les assertions comme il faut pour mon java -ea (toutes les post+invariant avant chaque return et pre à la première ligne de chaque méthode) ? ca serait hyper cool !!

Les tags @pre, @post et @invariant ne sont pas reconnus en standard par JavaDoc ou le compilateur Java. Par contre, rien ne t'empêche d'étendre JavaDoc avec des taglets afin qu'il les reconnaisse.
Mais cela ne permettra que d'augmenter la richesse d'expression de la documentation fabriquée par JavaDoc, pas du code généré par le compilateur Java. Il serait peut-être judicieux d'en faire la proposition à Sun (via une JSR), pour que Java se rapproche un peu d'Eiffel !    

 
Concernant les doclets, on peut modifier le code avec ? car il faut générer des assert avant tous les return.
 
C'est un des avantages du système de modification de la syntaxe d'O'caml (camlp4), on peut traffiquer l'arbre syntaxique en live (ce qui serait très utile ici).
 
Depuis au moins 1996 des voix s'élèvent contre l'absence de contrats (et, dans un autre registre, de généricité) dans java.

Relis mon post précédent, c'est ce que je disais (peut-être pas assez clairement) : les taglets enrichiront le JavaDoc généré, mais le compilateur ne sera pas plus intelligent.

Oui, mais si ce sont des chercheurs ou des théoriciens, Sun s'en fout. Il faut que ce soit des utilisateurs qui le demandent. Beaucoup d'utilisateurs. La meilleure preuve, c'est que pour la généricité, Sun va modifier le langage pour le JDK 1.5. Donc ça marche (même si c'est long).

 
je pensais à tirer des .java (ou même des .class, à la caml) "enrichis en qualité".

 
L'inovation par les techniciens, on l'attend encore.

Ben quand les techniciens innovent, le reste de l'industrie refuse de suivre. Les exemples sont légion...  

 
J'aurai plutot conseillé un bouquin d'algo genre "Introduction to algorithmics" (T. Cormen, R. Leiserson, R. Rivest)

 
Hmm j'ai fait un ou deux tds en java
ou les contrats étaient inclus dans le code sous forme d'asserts.
 
par contre je ne me souviens plus du nom de l'outil qui permettait de faire ça.  
 
Mais ce n'est peut-etre pas de ça dont
vous discutiez..
 
LeGreg

ben avec la jdk1.4 y'a le "assert", mais bon j'en sais pas plus

 
nan on parle pas de assert mais d'un outil qui genere ces assert
..  
enfin je crois parce que je suis un peu perdu
dans vos discussions  
 
LeGreg

 
Si on parle de la même discussion, t'es pas à la rue.
 
J'ai trouvé ça : http://jcontractor.sourceforge.net [...] ourse.html
 
ça a une bonne tête, je testerais un jour.