On Thu, Jun 27, 2002 at 02:38:18PM +0200, Yves Martin wrote:
>
> Alors je fais peut-être trop de cuisine.
> D'un autre côté, j'ai déjà vu des modélisations objet lourd-dingue
> et sans aucun design pattern. Bref c'est l'extrème opposé
L'un comme l'autre sont a eviter le plus possible.
Lorsque l'on a une modelisation objet lourd-dingue, des fois, cela
signifie que le ou les modeles objet ne sont pas bons.
>
> > > Mais alors montrez-moi le développeur qui fournit des tests
>> > unitaires
> > > automatiques (pour la non-régression) avec son code et vous dit:
> > > j'ai essayé de couvrir tous les cas.
> > >
>
> > Connais pas de tels developpeurs et c'est inutile en pratique.
>
> Alors tu ne travailles pas dans une boîte certifiée ISO 9002 ?
> c'est mon cas, et je fais le maximum de tests
> boite-blanche/boite-noire avec JUnit.
> Pour un GROS projet EJB qui dure 2 ans pour une assurance ou une
> banque suisse avec 15 développeurs (voir plus),
> les tests de non-régression sont indispensables.
> [ blablabla ]
Bon, on va commencer par eclaircir les choses :
- Je fais partie d'une boite certifiee ISO-9001
- Je n'ai jamais dis que les tests de non-regression ne sont pas
indispensdables. Ne me fait pas dire ce que je n'ai pas dis.
- Les tests qui recouvriraient tous les cas (si jamais c'etait possible)
sont inutiles en pratique. On fait une audit de code/fonctionnalites
et a partir du resultat de l'audit, on ecrit les tests qui recouvrent
le maximum du code/fonctionnalite utilise (le concept des 20%-80%)
> > dans certaines situations, le temps passe en tests avec un langage a
> > typage fort n'est pas largement inferieur a celui passe en tests avec
> > un
> > langage a typage dynamique.
>
> J'ai surtout de l'expérience en C, en Ada et en Java et les trier
> en fonction du temps "perdu" en tests me semble trivial:
> C (max de temps - segfault - pointeur non initialisé)
> Java (pas mal de temps - NullPointer)
> Ada (dépassement de tableau rarissime)
>
Autrement dit, tu n'as pas bcp d'experience avec un langage a typage
dynamique (Ruby, Python, CLOS, SmallTalk, et j'en passe des meilleurs.)
Ce qui expliquerait tes propos.
AMHA, lorsque l'on a affaire a un langage a typage static, il vaut mieux
que ce typage soit fort (ca c'est mon opinion et vaut ce qu'elle vaut).
C c'est bien pour de la programmation systeme ou pour faire des
librairies, mais sortie de ca ... (de plus ce n'est pas un langage
objet) (ca c'est mon opinion partage par d'autre, dont des developpeurs
C meme)
> Certes on peut se faire des outils de "design by contract" en C et en
> Java mais c'est mieux quand c'est fourni par le langage comme Eiffel.
>
Tout a fait d'accord
> Une petite question finallement:
> Comment modéliser un ?type énuméré"
> ou le concept qui lui correspond en objet ?
> Parce que pour l'instant je suis assez convaincu par ma "cuisine".
>
Du point de vue uniquement technique, ta "cuisine" est bien. De
pont de vue Objet, elle est ... "recette de cuisine" :)
La question n'est pas : "comment modeliser en objet un type enumere"
Ca ne veut rien dire et c'est pas ce que tu veux.
La question serait plutot : "Pourquoi ai-je besoin d'un type enumere ?
Qui en a besoin ?"
A partir des reponses a ces questions (qui peuvent donner d'autres
questions), tu arrives a une solution qui, finalement, peut amener a un
resultat tout simple.
Le pb en modelisation, c'est de ce poser les bonnes questions ; d'ou
s'exclure des considerations techniques et penser "Objet"
J'ai appris une chose en Objet : il est plus facile de faire compliquer
que de faire simple. Et lorsque l'on obtient une solution compliquee,
alors ce n'est pas la bonne solution. Si elle est simple, il y a de
grande chance que ce soit la bonne solution.
Prenons mon exemple pour illustrer les questions a se poser :
Je veux defninir l'ensemble des valeurs qui definissent les reponses
HTTP. En C on ecrirait ceci par exemple :
typedef enum {HTTP_OK = 200, HTTP_ACCEPTED = 202, ...} HttpResponse;
Mais, on est dans le monde objet et les choses sont differentes.
- Pourquoi ai-je besoin d'un type enumere ?
Pour definir les valeurs des reponses HTTP sous forme de chaine
symbolique (HTTP_OK, etc.)
- Pourquoi veux tu definir les valeurs des reponses HTTP sous forme de
chaine symbolique ?
Pour (dans mon cas) donner a l'utilisateur de la classe une meilleure
comprehension et lisibilite de ce que je lui retourne.
- Qui en a besoin ? L'objet qui retourne la reponse d'une requete HTTP
- Qui est cet objet ? un objet de la classe HTTPConnector (par exemple)
qui permet d'etablir des connexions HTTP persistantes ou non (pour la
persistance, avec HttpURLConnection de Java, on est plutot dans le caca)
Donc ces valeurs sont a definir dans la classe HTTPConnector. Exemple
d'implementation possible :
public class HTTPConnector {
public static final int HTTP_OK = 200;
public static final in HTTP_ACCEPTED = 202;
...
public void send (String messqge) {...}
public int responseCode () {...}
...
}
Cela signifie quoi ?
Que l'utilisateur pourra verifier du bon deroulement de l'envoie de sa
requete dans ce cas. Exemple :
if (connector.responseCode () != HTTPConnector.HTTP_OK) {...}
=> lisibilite et expressivite
Bien, sur. On peut definir ces constantes sous forme de String ou tout
autre. Pas uniquement d'entier.
Le pb que l'on peut rencontrer est ceci :
if (connector.responseCode () != 200) {...} // manque de lisibilite
ou
my_obj.doSomething (connector.responseCode ()) /* doSomething attend un
autre type de valeur symbolique comme par exemple :
public class My_class {
public static final int TOTO = 200;
..
/**
* elle attend une valeur symbolique pourle traitement
*/
public void doSomething (int symbole)
...
}
Note : my_obj est une instance de My_Class */
Dans ceis cas ci et similaires, c'est a l'utilisateur de savoir utiliser
correctement les choses, a coder correctement.
C'est en ce sens ou je disais qu'il ne faut pas voir les developpeurs tout
en noir et etre paranoiaque.
Un bon developpeur codera correctement les choses. Maintenant, tu
rencontreras toujours des rigolos ou des bricolos du dimanche.
Cette illustration de ce que je voulais dire n'est valable que dans des
cas similaires de representation. Mais les questions a se poser sont a
peu choses pres celles que je te propose.
--
Miguel Moquillon <miguel.moquillon@???>
http://miguel.moquillon.free.fr
