En réponse à Miguel Moquillon <miguel.moquillon@???>:
En ce qui me concerne la définition formel du type énuméré
m'importe peu tant que l'implémentation choisie en a l'usage.
Et c'est le cas pour la classe que je propose.
> C'est vrai, parce que ce ne sont que des entiers finalement, le
> developeur s'il veut faire crade, il peut en faire n'importe quoi ...
> l'equivalent du casting entre type enumere.
Là, je ne suis pas d'accord du tout. Tel que c'est fait, le développeur
est obligé d'utiliser les instances fournies.
Je veux bien un contre-exemple mais pas une affirmation telle quelle.
(Au passage, on ne parle pas de C++ mais de Java !)
> Mais s'il doit passer ces valeurs a une methode fournie par la classe,
> c'est a elle de gerer que ceci est correcte. Et ceci est bcp moins
> couteux que de definir une classe pour definir un type enumere,
> d'autant plus que cette representation, AMHA est douteuse en
> modelisation
> objet.
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é.
Dans ce cas précis, on consomme plus de mémoire (les instances du type
énuméré - qui sont de taille très raisonnables) mais on gagne en cycles
CPU par l'absence de check à chaque appel des méthodes concernées.
> De plus, il faut arreter de voir tout noir avec les developpeurs qui
> vont utiliser ta classe et donc a vouloir tout typer fortement la
> moindre parcelle de chose ! L'exemple de reussite des logiciels avec des
>
> langages a /typage/ dynamique prouve que les developpeurs savent coder
> correctement.
Oui c'est une réussite mais combien de fois le développeur peste sur
une erreur de runtime que le compilateur aurait pu trouvé.
Le typage fort et une expression du contrat des méthodes ont toujours
abouti à des langages 'lourds'. Je pense à Ada en particulier.
Mais le résultat est là:
- on passe beaucoup de temps à écrire le source mais 99 % des erreurs
possibles est rejeté à la compilation
- en définitive, il devient "presque" inutile de faire des
tonnes de tests pour assurer la converture du code,
ce qui reste conseillé malgré tout ;) !
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.
C'est pour cela que je préfère faire confiance au compilateur:
- on perd du temps à écrire le source pour qu'il passe la compilation
- on gagne beaucoup de temps sur la phase de tests
(car rares sont les tests qui échoue ensuite)
> Singleton : classe qui ne produit qu'UN seule objet dont l'etat evolue
> au
> gres des interactions. Un singleton ne produit pas plusieurs objets a
> valeurs uniques ! C'est faux, non seulement du point de vue pattern,
> mais aussi du point de vue Objet. Revoir son pattern :)
Au temps pour moi ... je vais réviser mes design-pattern !
--
Yves Martin
