En réponse à Miguel Moquillon <miguel.moquillon@???>:
> > Peut-être douteuse mais il est impossible de type-cast ce genre
> > d'objet
> > et la vérification à la compilation simplifie plus l'écriture
> > du code (par l'absence de check) et améliore son efficacité.
>
> Penser objet d'abord, penser technique apres. Ca evite de faire de la
> cuisine comme j'en rencontre trop souvent.
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é
> Non, c'est pas tout fait exacte. La creation d'objet en Java est non
> seulement
> couteux en memoire, mais en cycles CPU.
Oui bien sur, mais dans l'exemple d'énumération que je propose,
les instances en question sont construites par le constructeur
static, c'est à dire au chargement de la classe par le ClassLoader.
Bref, ces cycles CPU ne sont pas à prendre en compte puisque c'est
de l'initialisation (je fais beaucoup d'EJB en ce moment et tout
repose sur cette finesse).
> Quant au check il est non seulement leger mais il est aussi utilise
> que
> lorsqu'il est necessaire.
Oui, mais si on appelle beaucoup, beaucoup de fois la méthode
en question. Pas de check (dans mon cas, le strict minimum puisqu'il
s'agit du check d'équivalence de classe en runtime) vaut mieux
qu'un petit check 0 < enum < max else throw RuntimeException !
D'ailleurs quand le check échoue, c'est parfois tordé de savoir
ce qu'est devenu ton entier-énuméré pour arriver à cette valeur.
> > 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.
"inutile en pratique" me semble un peu cavalier comme affirmation.
Maintenant je ne doute pas que tu ais plus de pratique que moi qui
n'ai que 25 ans mais je suis sur que c'est loin d'être inutile mais
c'est dur de l'expliquer à un développeur débutant qui n'a pas encore
souffert le martyre à chercher chaque mois LE bug qui revient toujours le
mois d'après parce que son copain développeur à changer le "contrat"
de la classe qu'il utilise !
Si le "contrat" en question est vérifiée par un test unitaire c'est
déjà plus facile.
> Non, tu passes peut etre moins de temps en tests (ca reste encore a
> prouver), mais pas tant que ca. Je me base sur mon experience et sur
> celles de personnes que je ou j'ai cotoye. Ce qui ne veut pas dire que
> 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)
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.
Bref, il est inutile de faire plus de reproches à Sun pour Java,
d'autres l'ont fait pour nous.
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".
--
Yves Martin
