On Tue, Jun 25, 2002 at 04:24:41PM +0200, Yves Martin wrote:
> En réponse à Miguel Moquillon <miguel.moquillon@???>:
>
>
> Le problème d'utiliser un 'entier' ne contraint en rien l'utilisateur
> à respecter des valeurs
C'est pourquoi j'ai rajoute en commentaire :
"Ok, c'est un int, [...]"
Le probleme du type enumeree en objet releve a repondre a ces questions :
qu'elle est son utilitation ? pourquoi? et qui necessite ce type ?
Lorsque j'ecris :
public class HTTPConnector {
public static final int HTTP_OK = 200;
public static final int HTTP_ACCEPTED = 202;
...
}
cela signifie que les valeurs sont gerees par la classe meme qui en a
besoin.
Maintenant; qu'est ce un type enumere ?
Generalement, les types enumeres sont proposes pour fournir a
l'utilisateur un moyen de manipuler des constantes symboliques, plus
parlant, que des entiers. L'ensemble de ces enumerations forme un type
enumere nomme. Le nom de l'ensemble permet de dire a l'utilisateur
(developpeur) qu'est ce qui est attendu la ; et si ceci est tres utile
en procedural, il est bcp moins en objet de par sa nature meme.
Mais, par exemple en C, rien n'oblige le developpeur de faire un cast
entre types enumeres par la nature meme de ces types.
Maintenant revenons a notre cas. La classe propose a l'utilisateur des
constantes symboliques qu'il peut utiliser avec des objets de la classe.
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.
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.
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.
>
> Bien que l'objet puisse avoir des attributs et des états,
Non. Un objet est defini par des etat et un comportement. Attribut n'est
qu'une technique fournie par les langages de programmations objet.
> il existe le pattern de "singleton", objet unique du système.
> On peut donc définir une class par type énuméré, et un singleton par
> instance possible de ce type
>
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 :)
--
Miguel Moquillon <miguel.moquillon@???>
http://miguel.moquillon.free.fr
