Héritage "est un"

Bonjour,

J'ai un petit soucis là, j'ai du mal à mapper le problème suivant (j'dois mal m'y prendre)

Prenons 3 entités (c'est un exemple, mais l'idée est là) :
Personne
Peintre
Carreleur

Un peintre est une personne.
Un carreleur est une personne.
Une personne peut être un peintre ET un carreleur.
Une personne peut aussi n'être rien du tout (juste une personne, sans "rôle" particulier)

Illustration :

Code:

---

1 2 3 4 5 6 7 8

table personne table peintre table carreleur id id id 1 1 2 2 4 4 3 5 4 5

---

Comment je mappe ça avec JPA ?

J'ai essayé de la manière suivante, mais c'est pas bon, puisque chaque entrée est unique (un peintre ne peut pas être un carreleur) :

Code:

---

1 2 3 4 5 6 7 8 9 10

@Entity @Inheritance(strategy = InheritanceType.JOINED) public class Personne extends AbstractEntity   @Entity public class Peintre extends Personne   @Entity public class Carreleur extends Personne

---

Bien évidemment si j'essaye de faire ça, c'est parce que la personne a ses méthodes propres, le peintre aussi et le carreleur également...

Mais j'm'y prends ptete mal, y'a ptete un design pattern qui réponds mieux que l'héritage à ce problème ?

Tu dois placer cette annotation avant la définition de la classe Personne

Code:

---

@MappedSuperclass

---

Essayes de réviser tes cours d'héritage :ccool:

:nono:

C'est pas ça que j'essaye de faire.
Par correction, j'ai quand même essayé, au cas où. L'annotation @MappedSuperclass est utile notamment pour définir une classe utilitaire comme je le fais avec la "AbtractEntity".

Je cite la doc d'hibernate à ce sujet :
This is sometimes useful to share common properties through a technical or a business superclass without including it as a regular mapped entity (ie no specific table for this entity). For that purpose you can map them as @MappedSuperclass.

Ce n'est pas ce que j'essaye de mapper, puisque je veux inclure la classe Personne. Une personne peut très bien exister dans mon système sans avoir les propriétés additionnelles d'un peintre ou d'un carreleur. Et c'est bien ça mon problème, j'essaye de stocker dans Personne toutes les propriétés d'une personne, puis dans les tables filles, toutes les propriétés additionnelles d'une personne quand en plus, elle "est" un peintre.

Note : j'ai pris un exemple trivial, ce n'est bien évidemment pas le cas réel.


L'autre solution expérimentée est de ne pas avoir d'héritage. Dans ce cas, les tables "carreleur" et "peintre", sont de fait des tables de liaisons many-to-many avec par exemple une table "ouvrage".
Ce qui me chagrine un peu dans ce cas de figure, c'est que je perds la notion "est-un". Dans mon cas justement, elle est très importante.

Citation:

---

Un peintre est une personne.
Un carreleur est une personne.
Une personne peut être un peintre ET un carreleur.
Une personne peut aussi n'être rien du tout (juste une personne, sans "rôle" particulier)

---

Ce que tu décris là ce n'est pas de l'héritage. "Carreleur" et "Peintre" doivent plutôt être des rôles (métier ?), associés à une personne ; chaque personne a un ou plusieurs rôles (par exemple dans ta classe Personne, tu auras une liste de rôles).

Oui c'est un peu ça. Sauf que là, j'ai pris un exemple trivial, qui n'a rien à voir avec le cas réel.

Dans mon cas, un Carreleur EST une personne, une personne "étendue".
Pour être clair, ma personne peut avoir près de 10 rôles en même temps dans la base. Sauf que chacun de ces rôle est une entité à part entière. Chaque rôle à des associations et des méthodes qui lui sont propres.

Je conçois bien que l'héritage n'est pas le plus adapté, j'essaye simplement de remplacer la solution bancale actuelle par quelque chose de plus propre.

Note pour plus tard : ne plus donner des exemples pseudos-concrets :mouarf:

Citation:

---

Je conçois bien que l'héritage n'est pas le plus adapté, j'essaye simplement de remplacer la solution bancale actuelle par quelque chose de plus propre.

---

À mon avis, il faudra éviter l'héritage. L'exemple n'étant pas correct, je pourrai pas te donner d'autres pistes.

Ah mais l'exemple est correct, c'est juste que j'ai mis des noms réels dessus alors que je n'aurais pas du.

En gros, j'ai une entité X
puis une dizaine d'entités, A, B, C, D, E, F...
Qui sont des entités X (comprendre qu'elle ont tout les attributs, toutes les méthodes de X) et qui chacune à ses attributs et ses méthodes complémentaires.

Le seul soucis, c'est que X peut être à la fois X, A, B, C, D,... et je ne veux stocker les informations de X en base qu'une seule fois.

Dans le cas présent pour le moment, j'ai mis une relation 0-1 entre X et les classes filles. Ainsi A à un attribut X auquel il délègue tout les appels de méthodes de X.

C'est pour ça que je me demandais s'il n'étais pas possible de remplacer ce schéma par un héritage (mais ça me semble compromis, puisque je n'ai vu aucun exemple permettant d'avoir plusieurs enfants pour le même parent, typiquement :

Code:

---

1 2 3 4 5 6 7 8 9 10

Table X : id : 1 nom: blabla   Table A : ParentId : 1 attr:blablaA   Table B : ParentId : 1 attr:blablaB   Dans le cas là, X est un objet X, mais X est aussi un objet A et un objet B.

---

C'est de suite nettement moins clair avec des lettres, mais au moins on ne se pollue pas l'esprit avec des mot qui ont un sens ;)

Citation:

---

Le seul soucis, c'est que X peut être à la fois X, A, B, C, D,

---

Personnellement, je ne comprends strictement rien à ton problème (je confirme, c'est pire avec des lettres). Je pense que ce dernier provient d'une mauvaise conception, et je ne pourrai pas t'aider sans comprendre le domaine que tu essaies de modéliser. Il me semble fort curieux que tes entités soient de plusieurs types concrets à la fois (et héritant entre eux si j'ai bien compris), avec autant de similitudes entre ces types. Ou alors il y a une subtilité que je ne vois pas :oops:
X ne devrait-elle pas être abstraite ?

Citation:

---

X ne devrait-elle pas être abstraite ?

---

Non justement, parce que dans 50% des cas, j'utilise X tel quel (et surtout, X est "seulement" X, cad n'a pas d'entités fille). J'ai donc absolument besoin de pouvoir instancier X.
Ensuite, dans certains cas, X "devient" A. C'est à dire que A est un objet X, plus quelques attributs et méthodes. Dans d'autres cas, X "devient" B etc.

Intuitivement, j'ai pensé à de l'héritage, mais ça a l'air problématique. On parle bien ici de "rôles", sauf qu'il ne m'est pas possible de rajouter un attribut rôle comme dans le (mauvais) exemple avec les métiers. Rien que parce que X peut jouer le role de A, de B, de C etc... un attribut de discrimination n'est donc pas du tout adapté.

J'ai pensé à de l'héritage parce que j'ai le souvenir d'avoir lu un article qui, au sujet de la stratégie JOINED, expliquait que c'était la seule solution quand une même ligne de l'entité mère pouvait se référer à plusieurs entités fille.
(Sauf que évidemment, j'arrive pas à remettre la main sur cet article...)

Pour le moment, la solution que j'ai gardé est la suivante :
- une interface I qui définit toutes les méthodes de X
- X qui implémente I
- A qui implémente I et qui délègue tout à un objet X embarqué (par une relation 1-1)

Pas sur que ce soit la meilleure solution mais bon...