Discussion :

[Miko95]

Bonjour,

J'étudie en ce moment un standard de communication dans lequel est défini un modèle de données.
Dans le modèle, il y a une classe abstraite A avec certains attributs et une classe B qui hérite de A avec de nouveaux attributs. Ce qui me gêne, c'est que l'ensemble d'attributs qui permet d'identifier de manière unique une instance de B contient des attributs de A mais aussi des attributs de B.
Et je me posais la question de savoir est ce qu'il y a la une erreur de conception?

Merci d'avance

[sevyc64]

Je ne suis pas très point sur la question, mais, perso, ça ne me pose pas de problème.

Puisque tu veux identifier une classe B, tu ne peux te servir que d'attributs appartenant à la classe B. Que ces attributs soient hérités de A ou pas, ils font partie intégrante de B.

De plus, A est une classe abstraite. C'est à dire que ce n'est pas vraiment une classe. A est plus à voir comme un modèle, un moule avec lequel tu va fabriquer des classes, B en l'occurrence.

De faire hériter B de A, tu préfabrique ta classe, il ne te reste plus qu'à rajouter quelques petites modif pour en faire ta classe B spécifique. Au final, tu obtient une classe B comme si tu l'avais fabriquer de toute pièce en partant de 0.

Ceci dit, c'est mon interprétation, et je ne suis pas forcément un expert en la matière.

[Miko95]

Merci pour la reponse mais dans ce cas, comment est ce qu'on represente ca en UML ?

[bruno_pages]

Bonjour,

comme sevyc64 avec les infos dont on dispose je ne vois pas où serait le problème, si un ensemble d'attributs de A permet d'identifier de manière unique une instance de A alors en fait on se moque pas mal des attributs propres à B au niveau identification

qu'elle est la question relative à UML ? définir deux classes ayant des attributs et une relation d'héritage c'est très basique, ajouter une contrainte indiquant que les valeurs de attributs x, y ... z définissent de façon unique une instance n'est pas très compliqué non plus.

en fait ce qui me gène c'est le concept même d'un ensemble d'attributs définissant de façon unique une instance, qu'elle est le but de la chose ? [edit]je n'avais pu vu le titre [/edit]

[sevyc64]

qu'elle est la question relative à UML ?

Je pense que le problème doit plutot être "Comment identifier en UML, une classe comme étant abstraite, et comment la lier aux classes réelles qui en découleront ? "

Ceci dit, ne connaissant rien à l'UML, mon énoncé n'a peut-être aucune pertinence

[bruno_pages]

la propriété isAbstract indique si une classes est ou non abstraite, dans un diagramme une classe abstraite a son nom en italique

un héritage/ généralisation se représente via une flèche ----|> dans le cas standard, dans le cas présent il s'agit de réalisation et le trait est en pointillé - - - - -|>

[wiztricks]

Salut,

l'ensemble d'attributs qui permet d'identifier de manière unique une instance de B contient des attributs de A mais aussi des attributs de B

Il faudrait peut être clarifier un peu.
Est ce que plusieurs B pourront être "accrochés" au même A ou est-ce que la relation est univoque: tous les B ont des identifiants différents sur la partie A.
- W

[ego]

ouhai, je confirme, on en comprend pas quel est ton problème

[Miko95]

Merci pour les reponses,

Ma question est tout simplement, dans le cas ou l'on a une classe A abstraite et une classe B heritant de A, est ce qu'il est necessaire que les attributs se trouvant dans A seulement permettent d'identifier de maniere unique une instance qui herite de A. Ou est ce que pour identifier une instance qui herite de A, on peut utiliser des attributs de A et de B.

[CinePhil]

Je ne comprends pas plus la question mais je vois "clé primaire" dans le titre de la file de discussion.

Quand on parle de clé primaire, je ne sais pas si ça s'applique à autre chose mais chez moi on parle de clé primaire d'une table de BDD SQL.

Un héritage de tables s'implémente en BDD de la façon suivante :

MCD :
B -(1,1)---Etre----0,1- A

Tables :
A (a_id...)
B (b_id_a...)

La clé primaire de la table B est portée par la colonne b_id_a qui est une clé étrangère faisant référence à la clé primaire de A.

Mon passage douloureux sur la planète Seam me remet en mémoire que pour mapper ce modèle avec Hibernate,il ne faut pas mettre de propriété b_id_a dans la classe B mais utiliser les @nnotations pour figurer la dépendance.

[wiztricks]

Ma question est tout simplement, dans le cas ou l'on a une classe A abstraite et une classe B heritant de A, est ce qu'il est necessaire que les attributs se trouvant dans A seulement permettent d'identifier de maniere unique une instance qui herite de A. Ou est ce que pour identifier une instance qui herite de A, on peut utiliser des attributs de A et de B.

Le problème est que la relation d'héritage est une relation entre classes.
Si B hérite de A, rien n'interdit d'avoir plusieurs instances de B associées à un même A.
Regardez par exemple le "composite pattern" ou considérez une hiérarchie de répertoires contenant des fichiers et des répertoires.

La question reste de savoir quelles sont les réalités qu'on a voulu représenter.
- W
PS: Pardon Cinephil, oui tu as raison, mais entre UML et DDL le chemin est assez sinueux surtout lorsqu'on parle de concept "objets" tels que l'héritage.

[sevyc64]

Le problème est que la relation d'héritage est une relation entre classes.
Si B hérite de A, rien n'interdit d'avoir plusieurs instances de B associées à un même A.
Regardez par exemple le "composite pattern" ou considérez une hiérarchie de répertoires contenant des fichiers et des répertoires.

ATTENTION, il ne faut pas perdre de vue les termes employés.

A est une classe abstraite.
Le terme "Classe" est ici trompeur même si c'est le terme officiel. A n'est pas et ne sera jamais une classe, c'est juste un modèle de fabrication. Il n'existera jamais d'instance de A

B hérite de A.
Ici aussi "hérite" est un terme trompeur même si c'est là aussi le terme officiel. B n'héritera jamais de A puisque A n'existera jamais. B sera construit de toute pièce sur un modèle de base A.

Donc on n'aura jamais "plusieurs instances de B associées à un même A", car même si elles prennent le terme de classe filles, les instances de la classe B seront techniquement toujours des classes mères, donc totalement indépendante.
Selon le même principe de terminologie on devrait plutôt appeler les classes B, classes mère réelle, et les classes A, classe mère abstraite ou classe mère virtuelle.

Donc à la question

est ce qu'il est nécessaire que les attributs se trouvant dans A seulement permettent d'identifier de maniere unique une instance qui herite de A. Ou est ce que pour identifier une instance qui herite de A, on peut utiliser des attributs de A et de B.

La réponse pourra être la suivante :
Les attributs identifiants une instance de B seront toujours de B. Ceux-ci, pouvant être des attributs d'origine de A, spécifique de B, ou un mélange des 2.

A noter que les méthodes présentent dans la classe abstraite A ne peuvent faire appel qu'à des attributs de la classe A. Si ces méthodes doivent aussi faire appel à des attributs de la classe B, il faudra alors surcharger la dite méthode dans l'implémentation de B.

[wiztricks]

La réponse pourra être la suivante :
Les attributs identifiants une instance de B seront toujours de B. Ceux-ci, pouvant être des attributs d'origine de A, spécifique de B, ou un mélange des 2.

C'est bien mais la question est côté "identifiants" et mutabilité.

Maintenant imaginez un C qui hérite de A sans être un B.
Instancions:
c = (id_a, ..., id_c, ....)
b = (id_a,..., id_b,...)
Les ... représentent des attributs "mutables" de l'instance provenant de A et de B ou C.
Si une instance de B est identifiée par (id_a, id_b), id_a n'identifie rien du tout puisque plusieurs B pourront être associés aux mêmes id_a ayant des attributs différents.
Autrement dit, id_a n'est pas, dans ce cas, un "identifiant" (i.e. une clé associée à un uple d'attributs de valeurs identiques).

Pire, en disant "attribut", on ne précise pas vraiment ce qu'ils sont: valeur ou "pointeur" vers un agrégat - qui pourrait être partagé...

ATTENTION, il ne faut pas perdre de vue les termes employés.

L'héritage nous permet de dire que B et C sont des A.
A étant "abstraite", on ne pourra pas l'instancier "directement".
Les termes employés ne nous disent rien de plus sur la nature des attributs de A et de B et encore moins sur les propriétés que pourrait avoir un "identifiant".

- W