Problème conception : des classes ayant seulement des attributs différents peuvent-elle hériter d'1 class mère

Bonjour

Le titre n'est peut être pas explicite je vais donc essayer de détailler.

Supposons une classe A, ayant des méthodes publiques, et des attributs privés (jusque là, on doit me suivre ^^)

Supposons que le cahier des charges stipule que des choses dites "A" ont les mêmes comportements (méthodes et leur implémentation donc), mais qu'il existe plusieurs sous catégories de A. Les seules différences entre ces sous catégories étant les valeurs possibles des attributs, et non pas l'implémentation des méthodes.

Par attributs, je peux sous entendre attributs liés aux sous catégories elles mêmes, et non pas aux instances.

Par exemple, tous les instances A1 ont un prix de 1000, toutes les A2 un prix de 300. Ces 2 instances font les mêmes choses de la même façon, sauf qu'elle ne coutent pas pareil.

Comment pensez vous que ça se modélise ?

J'étais parti sur un héritage mais je me suis vite aperçu que tout ce qui est constant et statique en Java ne peut être hérité. J'ai commencé à me demander si j'avais bien analysé. Et finalement, c'est vrai que c'est pas une spécialisation puisque les fonctionnalités sont identiques.
Pouvez vous confirmer mon raisonnement ?

En ce moment, je me dis qu'une factory doit créer les instances de A, avec les attributs qui vont bien en fonction de la catégorie.
Par exemple, une énumération (pouvant être A1, A2 ...) est passée à la factory, et en fonction de ça, elle instancie avec les valeurs des attributs dépendant de cette catégorie (si A1, alors new a.prix = 1000 ...). Et pour différencier les catégories des instances, faire un attribut sous catégorie dans A (défini par la factory), accessible depuis l'extérieur.
Qu'en pensez vous ?

Citation:

---

Envoyé par azerty25

Par exemple, une énumération (pouvant être A1, A2 ...) est passée à la factory, et en fonction de ça, elle instancie avec les valeurs des attributs dépendant de cette catégorie (si A1, alors new a.prix = 1000 ...).

---

Ça, ca me semble pas mal.

Bonsoir
Personnellement, j'associerai à chaque instance de "A" une entrée prise dans la liste de Catégories associées pour avoir le nom, le prix,...
Nota sous la forme d'un pointeur vers l'élément de la Catégorie ou son numéro d'ordre dans la liste.
Et si le 'client' de A ne veut pas "voir" l'indirection? ben, je ne sais pas la syntaxe Java pour çà mais il devrait être possible de creer un décorateur
de type getter/setter qui retourne le prix de a lorsqu'on accède à a.prix
- W

Merci pour vos réponses, tout d'abord.

wiztricks>

Si j'ai bien compris, avec ta solution, j'ai une classe Catégorie, avec les différentes instances qui représentent les catégories possibles, avec leurs attributs initialisés ?
Il faudrait garder les instances quelque part. Et quand je voudrais savoir de quelle Catégorie est un A, je vais avoir quelque chose comme instanceA.type == factorySingletonCategories.get(X).
De même, pour créer les A, on aurait quelque chose comme factorySingletonCategories.createA(factorySingletonCategories.get(X)).
Bon je suis pas très expérimenté, je dis peut êtres des conneries, mais c'est pas un peu trash ? ^^
Mais c'est vrai que conceptuellement, on est bien en présence de Catégories qui ont des caractéristiques propres.

Avec l'autre solution, on perd ces Catégories qui sont connues que par la factory, mais pour savoir le type (catégorie), c'est assez simple: monA.type == Enum.X

Ben moi je ne suis pas d'accord avec vous.
Si par essence tu as des sous-classes qui ont des valeurs fixes pour certains attributs alors il faut modéliser cela structurellement = avec l'héritage.
Il ne faut pas substituer une réelle notion de sous-classes avec des factories car ce n'est la même chose.
J'ai mis une copie d'écran de ce que cela peut donner en UML.

Notez le "readonly" et la valeur par défaut.

Ensuite, côté Java par exemple, on ne propose qu'un "getter" sur attr1 au niveau de A1 et la valeur est mise initialisée dans le constructeur de A1

Ego
Ta proposition fonctionne et est semblable à celle que j'essayais de proposer.
Ceci dit...

azerty25

Citation:

---

Si j'ai bien compris, avec ta solution, j'ai une classe Catégorie, avec les différentes instances qui représentent les catégories possibles, avec leurs attributs initialisés ?

---

Ben globalement, il s'agit de constantes "initialisables" depuis une BDD ou un fichier. Si nous évitons l'héritage, nous évitons peut être aussi d'avoir à recompiler le code en cas de mise à jour des catégories.
Côté structure, ca à la même gueule que présente le schéma d'ego, héritage en moins...

Citation:

---

Il faudrait garder les instances quelque part. Et quand je voudrais savoir de quelle Catégorie est un A, je vais avoir quelque chose comme instanceA.type == factorySingletonCategories.get(X).

---

Je ne sais pas qui est X mais le nom/type d'une catégorie est un identifiant adhoc... que l'application connaît ou pas.

Citation:

---

De même, pour créer les A, on aurait quelque chose comme factorySingletonCategories.createA(factorySingletonCategories.get(X)).
Bon je suis pas très expérimenté, je dis peut êtres des conneries, mais c'est pas un peu trash ? ^^

---

Absolument mais çà me parait un peu compliqué!
Pour initialiser l'instance de A, n'avons nous pas simplement besoin d'un entier ou d'un pointeur vers la catégorie correspondante?
Lorsqu'on cherche a savoir de quel type est l'instance ou quels sont les attributs figés par la catégorie on fait une indirection pour récupérer ce qu'il y a dans l'instance catégorie associé à l'instance.

i.e. faire un "getter" de la forme:

Code:

---

1 2 3

public 'type' get<Attribut>() { return self.categorie.<Attribut> }

---

-W

Citation:

---

Envoyé par azerty25

Bonjour

Le titre n'est peut être pas explicite je vais donc essayer de détailler.

Supposons une classe A, ayant des méthodes publiques, et des attributs privés (jusque là, on doit me suivre ^^)

Supposons que le cahier des charges stipule que des choses dites "A" ont les mêmes comportements (méthodes et leur implémentation donc), mais qu'il existe plusieurs sous catégories de A. Les seules différences entre ces sous catégories étant les valeurs possibles des attributs, et non pas l'implémentation des méthodes.

Par attributs, je peux sous entendre attributs liés aux sous catégories elles mêmes, et non pas aux instances.

Par exemple, tous les instances A1 ont un prix de 1000, toutes les A2 un prix de 300. Ces 2 instances font les mêmes choses de la même façon, sauf qu'elle ne coutent pas pareil.

Comment pensez vous que ça se modélise ?

J'étais parti sur un héritage mais je me suis vite aperçu que tout ce qui est constant et statique en Java ne peut être hérité. J'ai commencé à me demander si j'avais bien analysé. Et finalement, c'est vrai que c'est pas une spécialisation puisque les fonctionnalités sont identiques.
Pouvez vous confirmer mon raisonnement ?

En ce moment, je me dis qu'une factory doit créer les instances de A, avec les attributs qui vont bien en fonction de la catégorie.
Par exemple, une énumération (pouvant être A1, A2 ...) est passée à la factory, et en fonction de ça, elle instancie avec les valeurs des attributs dépendant de cette catégorie (si A1, alors new a.prix = 1000 ...). Et pour différencier les catégories des instances, faire un attribut sous catégorie dans A (défini par la factory), accessible depuis l'extérieur.
Qu'en pensez vous ?

---

Merci pour vos réponses très intéressantes. On a finalement opté pour l'héritage avec initialisation des attributs par les constructeurs des classes filles, dans l'hypthèse d'évolution des comportements de celles-ci (ce qui n'était finalement pas exclus)

Bonne année à vous !