Discussion :

[FRED.G]

De toute façon c'est pas comme si tu avais le choix. Tu ne peux pas hériter à la fois d'Employe et de Client, d'autant qu'hériter d'une classe concrète n'est pas des plus conseillés. Et même si tu pouvais, tu aurais des problèmes avec les champs et méthodes de même nom de ces deux classes. Tu aurais le problème habituel de l'héritage multiple, à savoir de décider quand tu appelles un membre hérité de la classe de base, si c'est la classe de base côté Employe ou côté Client. Sans parler du côté de la base de données où ce serait un peu abominable à gérer.

Côté base de donnée, je fais confiance à SQL Pro pour nous donner un exemple fiable (cf. le schéma fourni en PJ). Pour le problème de l'héritage multiple, plutôt que de l'éviter par un glissement sémantique et le recours à la composition, je suggérais de typer les entités métiers à l'aide d'interface uniquement...
Un tel usage des interfaces me parait très souple !

Je serais donc tenté de te demander quels reproches tu fais à cette "solution", mais apparament tu as donné ta réponse :

Une même classe qui cumule les responsabilités d'un employé et d'un client, ça ne va pas. une classe représente un seul concept, pas plusieurs. S'il s'agissait de 'décorer' une classe avec de nouveaux attributs, ok (pour le coup on retombe dans les patterns . Mais là non. Il s'agit de cumuler deux concepts différents. Pas une bonne idée

En pratique, je ne vois pas bien où serait le souci avec ma solution d'interfaces... Mais peut-être suis-je victime ici de mon manque d'expérience !


Je voudrais ajouter une chose concernant ce débat : vous êtes nombreux à avoir discuté l'exemple que j'ai donné avec mes entités "Contact", "Client, "Personne", etc. Mais j'ai encore du mal à savoir si ces critiques révèlent un mauvais exemple pour une problématique légitime ou si c'est la problématique qui n'a pas lieu d'être et rend ainsi bancale toute tentative d'exemple.

Dans le premier cas, il me suffirait de trouver un meilleur exemple. Je pensais qu'en reprenant celui de SQL Pro, tout le monde serait d'accord. Dans le fond il s'agit d'illustrer simplement le cas où une instance d'une entité mère peut être hérité par des instances de plusieurs entités filles (une instance par type enfant, cf. le schéma joint). Personnellement, je ne vois rien de choquant à cela.

[Kelpan]

Au final tu as 4 classes

Classe Personne
Classe Client héritant de Personne
Classe Employe héritant de Personne
Classe Prospect héritant de Personne

Une Classe qui reprsenterait une personne qui soit à la fois Client et Employé n'a aucun sens.

Cepandant, rien n'empeche d'avoir dans ta base de donnée de lier une même personne à la table Client, à la table Employé, voire la table Prospect...

Une même personne peut donc être gérer en tant que Client, Employé, mais pas les 2 à la fois.
C'est comme si tu demandais à ta classe de gérer 2 tables à la fois...

[Maniak]

Côté base de donnée, je fais confiance à SQL Pro pour nous donner un exemple fiable (cf. le schéma fourni en PJ). Pour le problème de l'héritage multiple, plutôt que de l'éviter par un glissement sémantique et le recours à la composition, je suggérais de typer les entités métiers à l'aide d'interface uniquement...
Un tel usage des interfaces me parait très souple !

Ah mais je n'ai absolument rien contre l'utilisation des interfaces dans ton cas, au contraire, je vais plutôt dans ce sens justement :)

Simplement à partir du moment où tu passes par des interfaces, tu n'as plus besoin de te trainer un héritage problématique comme il y a dans ton exemple, et tu peux passer par de la composition. Ça élimine le problème d'héritage, tu peux cumuler toutes les interfaces dont tu as besoin et la composition est masquée par ces mêmes interfaces. Au lieu d'hériter, tu rediriges. C'est tout.


Si tu as des interfaces IContact, IEmploye, IClient et des classes correspondantes, tu peux facilement te faire une classe EmployeClient qui implémente à la fois IEmploye et IClient, et qui est composée d'un objet implémentant IEmploye et un autre implémentant IClient. Tu rediriges simplement les appels à l'un ou l'autre selon les besoins.
Conceptuellement parlant, une classe qui représente à la fois un employé et un client me parait toujours douteux, mais si on doit faire comme si c'était nécessaire, soit :)

Dans la même lignée, une classe Employe qui implémente IEmploye et IContact n'a pas besoin d'hériter d'une classe Contact. Elle a juste besoin de contenir une instance d'une classe implémentant IContact et à nouveau de rediriger les appels vers cette instance.

Quand l'héritage pose un problème, c'est généralement très simple de le retirer et de passer à de la composition, à partir du moment où on utilise des interfaces appropriées. Ça facilite la vie et ça évite de se retrouver avec des classes trop 'grasses', qui cumulent les fonctionnalités des 10 classes de base au-dessus.
C'est aussi plus clair pour le développeur. Tu n'as pas besoin de savoir que telle méthode non-déclarée dans ta classe correspond à la méthode d'une classe parente 2 niveaux au-dessus. Tu implémentes les interfaces dont tu as besoin, et tu sais exactement quels objets gèrent quelles parties puisque tu y rediriges les appels explicitement.

Avec une aborescence un peu complexe, si tu veux ajouter des fonctionnalités communes à plusieurs classes, tu dois chercher où les caser. Quand ça implique de créer une nouvelle classe de base, ça peut avoir des effets secondaires assez violents. Avec interfaces + composition, tu te fais une nouvelle classe avec les nouvelles fonctionnalités, tu en ajoutes une instance dans les différentes classes concernées, tu ajoutes l'interface dans la déclaration et tu rediriges les appels. Beaucoup moins de risques d'avoir besoin d'aspirine.

[Kelpan]

Par exemple, imaginons le cas de modélisation d'objets métier suivant : une entité Contact, et des entités plus spécifiques Client, Employé, etc. qui sont toutes des contacts... Comment modéliser un contact qui serait à la fois Client et Employé ?

Pour moi le problème vient de la question...

Dans quel cas a-t-on besoin d'avoir une classe qui soit à la fois Client et Employé ?

[FRED.G]

Dans quel cas a-t-on besoin d'avoir une classe qui soit à la fois Client et Employé ?

Ben quant un employé est aussi client...

[Kelpan]

Et alors, la question tient toujours.
A quoi cela servirait de modéliser un classe Client/Employé, cela n'a pas de sens.
Pour être plus concret et dépasser le stade de la modelisation ...
Quand tu auras ta classe Client/Employé, a quoi elle va te servir ?

Une personne ne peut pas être client et employé en même temps.
Pour autant une personne peut très bien être client pendant que tu gères tes clients et devenir employé pendant que tu gères tes employés, mais pas les 2 à la fois.

Désolé pour l'exemple, mais là maintenant, je trouve pas mieux :
Imagine un transformeur (si si les jouets robots qui se transforme).
A un moment, il est un robot et à un autre moment, il est un avion, par exemple, mais il ne peut pas être les 2 à la fois. Et pourtant c'est le même objet... (essaye de le faire voler pendant que c'est un robot ...)

[davcha]

Désolé pour l'exemple, mais là maintenant, je trouve pas mieux :
Imagine un transformeur (si si les jouets robots qui se transforme).
A un moment, il est un robot et à un autre moment, il est un avion, par exemple, mais il ne peut pas être les 2 à la fois. Et pourtant c'est le même objet... (essaye de le faire voler pendant que c'est un robot ...)

Ben ça vole ! Pas longtemps, mais ça vole....

Et puis, si c'est un nano-transformer il peut peut-être se trouver dans divers états en même temps, voir même dans différentes positions !...

Ok, je sors. Mais c'est grosso modo ce que je voulais dire également. Un peu fatigué moi.