Discussion :

[FRED.G]

Le recours à l'héritage de classe en modélisation objet est très fréquent. C'est d'ailleurs l'un des premiers sujets traités dans tout cours d'initiation à la POO. Néanmoins les classes .NET ne supportent pas l'héritage multiple, contrairement aux interfaces.

Sachant qu'une classe peut implémenter plusieurs interfaces,

ne pensez-vous qu'il existe de nombreux cas (je veux dire, plus qu'on ne le croit... ) où il est plus intéressant de privilégier le recours aux interfaces plutôt qu'à l'héritage de classes ?

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é ?

On ne peux pas faire hériter Client par Employé ou l'inverse, car tous deux ont déjà Contact pour classe de base. Dans un cas comme celui-ci l'héritage simple montre donc ses limites !

En revanche, le recours à des interfaces permettrait d'obtenir toutes les combinaisons que le modèle doit supporter (contact-client, contact-employé, contact-client-employé).

[dev01]

Salut .

Les interfaces et l'héritage ne servent absolument pas à la même chose.

Les interfaces définissent un contrat que les classes qui les implémentent doivent respecter afin de permettre une utilisation générique dans le reste du model.

L'héritage permet de ne pas réécrire des fonctions qui sont commune à une classe et à ses enfants. (ça c'est l'idée générale )

Dans ton cas la solution est simple il suffit de faire une chaine un peu plus grande :

Client hérite d' Employer qui hérite de Contact .

Bref je ne crois qu'il y ait un pb entre l'UML et le C#

[Mourad]

je suis tout à fait d'accord avec dev01 héritage et interface ce n'est absolument pas la même chose

[0xYg3n3]

Dans ton cas la solution est simple il suffit de faire une chaine un peu plus grande :
Client hérite d' Employer qui hérite de Contact.

Client n'est pas forcément employé.
Client peut être employé.
Client est un contact.

Avec ta proposition, Client est forcément un Employé
Regarde cu côté des design pattern tu trouveras certainement ce que tu cherches

[dev01]

Client n'est pas forcément employé.
Client peut être employé.
Client est un contact.

Avec ta proposition, Client est forcément un Employé
Regarde cu côté des design pattern tu trouveras certainement ce que tu cherches

Vu que c'est le cas qu'il veut je vois pas le pb ... dont son cas il veut qu'un contact soit un employé et un client ...

ça donne en tout 4 classes à écrire ...

[0xYg3n3]

J'ai mal du comprendre le sujet alors
Je pensais qu'un client n'était pas forcément un employé

PS: je ne donne pas cher de cette boîte

[dev01]

J'ai mal du comprendre le sujet alors
Je pensais qu'un client n'était pas forcément un employé

PS: je ne donne pas cher de cette boîte

Pas forcément mais il a le cas ou oui .

Maintenant si tu as une solution pour modéliser ça sans passer par une 4ème classe je suis preneur

[FRED.G]

Je reconnais que ma présentation du problème des contacts n'était pas suffisament bien présentée puisque dev01 ne m'a pas compris.

Mais je pense que cette fois tout le monde a saisi.

0xYg3n3, tu as compris tout de suite mon exemple, par contre, c'est vrai que ne m'y connnaissant pas en design pattern, je ne vois pas quelle solution tu evisages ! (Et j'espère qu'on ne sera pas trop jeunes pour comprendre tes explications ! )


A part ça si le sujet vous intéresse, essayez de vous concentrer plutôt sur le fond, c'est un débat, pas une arène !

[davcha]

Pour moi c'est simple, un client n'est jamais un employé, sauf si tu payes un salaire à tes clients évidemment...

Ce que je veux dire ici, c'est que même si le contact reste identique et que dans la réalité un employé peut devenir client de la société qui l'emploie ou qu'un ancien client peut être employé par une société, on ne parle pas de la même chose, même dans la réalité.

Autrement dit, si un jour un client (respectivement un employé) devient employé (respectivement client) d'une même société, il se retrouve dans deux états bien distincts : client ET employé, et cela, selon moi, ne se modélise pas en introduisant une 4e classe ClientEmployé, mais bien en instanciant deux classes distinctes : un objet Client et un autre objet Employé.

Dans un tel cas, dans la réalité, quand un employé achète du matériel chez l'entreprise qui l'emploie, il passe à la caisse en tant que client, comme tout autre client.
Et inversement, un ancien client qui est embauché reçoit un salaire en tant qu'employé, comme tout autre employé.

[FRED.G]

Je partage ton point de vue sur l'exemple contact / Client / Employé.

Mais au delà des limites de cet exemple, la problématique ne demeure-t-elle pas ? Même si je n'ai pas d'autres exemple sous la main, penses-tu qu'on puisse résoudre systématiquement ce genre de cas par une instantiation "sélective" ?

[FRED.G]

Salut à tous !

Je vais surtout répondre à la première réponse de dev01, elle contient l'essentiel de la contradiction tandis que le reste dégénère un peu.

Les interfaces définissent un contrat que les classes qui les implémentent doivent respecter afin de permettre une utilisation générique dans le reste du model.

L'héritage permet de ne pas réécrire des fonctions qui sont commune à une classe et à ses enfants. (ça c'est l'idée générale )

Merci pour ce bref rappel. Honnêtement je ne l'avais pas fait, pensant que tous les participants au débat maîtriseraient au moins ces notions. Je ne vais donc pas contredire ces propos, je voudrais plutôt essayer d'aller un peu plus loin...

Les interfaces et l'héritage ne servent absolument pas à la même chose.

"absolument pas", tu dis ? Je n'en suis pas si sûr du tout ! Si la différence était si évidente, on ne pourrait sans doute pas lire ceci dans la msdn :

Les interfaces et l'héritage de classes présentent chacun des avantages et des inconvénients, ce qui peut vous amener à associer l'utilisation des deux dans vos projets. La page Quand utiliser des interfaces et Quand utiliser l'héritage vous aideront à déterminer quelle est la meilleure approche pour votre situation.

Permet-moi donc d'être plus nuancé que toi, dev01.

Il existe plusieurs autres raisons qui peuvent vous amener à préférer les interfaces à l'héritage de classes :

• Les interfaces sont mieux adaptées aux applications exigeant la création de nombreux types d'objets pas nécessairement liés pour assurer certaines fonctionnalités.
• Les interfaces sont plus souples à utiliser que les classes de base, car il suffit de définir une seule implémentation pour pouvoir implémenter plusieurs interfaces.
• Les interfaces sont plus indiquées lorsque vous n'avez pas besoin d'hériter une implémentation d'une classe de base.
• Les interfaces sont utiles lorsque vous ne pouvez pas utiliser l'héritage de classes. Par exemple, les structures ne peuvent pas hériter des classes, mais elles peuvent implémenter des interfaces.

J'ajoute : "une classe peut implémenter plusieurs interfaces"...

Contrairement à ce que tu sembles penser, je trouve que les interfaces et l'héritage sont très proches. Le point commun fondamental selon moi est le polymorphisme. J'entends pas là le fait qu'une classe qui participe à une hiérachie d'héritage ou qui implémente des interfaces expose plusieurs types dans lequels elle peut être castée, reflétant ainsi une modélisation assez fine et plus près de la réalité.

Je pense qu'il y a matière à débat, parce qu'instinctivement, le développeur qui découvre la POO va développer en ayant recours à l'héritage. Or il me semble que dans certains cas, l'usage des interfaces est plus indiqué, là même où l'on penserait d'abord à l'héritage.

Prenons des exemples concrets. Dans le cas de composants d'accès aux données, les interfaces sont suffisament complexes à implémenter pour que le recours à une implémentation dans une classe de base soit un vrai gain en terme de réutilisation de code (et encore à l'origine, le modèle n'est-il pas défini par des interfaces ?...).
Mais si on prend le cas d'une modélisation d'objets métier, les limites de l'héritage peuvent plus facilement se faire ressentir.
Déjà, le gain en terme de "factorisation" de code grâce à sa définition unique dans une classe de base est parfois faible, voire nul : soit qu'il y a peu de code écrit (et là un copié / coller est très efficace, et je ne parle même pas de l'utilisation de générateur de code qui élimine toute la problématique de la saisie de code répétitif), soit que ce code doit être redéfini (mustoverride / virtual, overrides, etc.) dans les classes enfants...
Pour finir, il y a bien des cas que tu ne peux pas modéliser correctement. Dans celui que j'ai cité, tu réponds à côté :

Client hérite d' Employer qui hérite de Contact

C'est une aberration ! Tous les clients sont des employés... :s

Conclusion : je pense sérieusement à définir mon modèle métier uniquement à partir d'interfaces, même lorsque je n'ai pas de cas "d'héritage multiple" à gérer.

Voilà, j'ai évoqué ici le cas d'une modélisation "métier" d'entités de type "contact".
Un ancien resp de la rubrique DotNet, au sujet de ce cas concret m'avait fait ce commentaire (avec un lien très intéressant mais qui n'entre malheureusement pas dans mes compétences ) :

En fait c'est à cause de ce genre de problématique que les gurus de l'architecture déconseillent de plus en plus l'héritage. Prends une aspirine, lis l'article de Patrick Smacchia sur l'héritage d'implémentation dans les langages objets et reprends encore une aspirine

Donc on délaisse l'héritage au profit des interfaces

[0xYg3n3]

C'est une aberration ! Tous les clients sont des employés... :s

Ca n'avait pas l'air de les choquer

[Nip]

Le recours à l'héritage de classe en modélisation objet est très fréquent. C'est d'ailleurs l'un des premiers sujets traités dans tout cours d'initiation à la POO.

Je te suis totalement la dessus, c'est vrai que l'heritage c'est presente comme la voie royale de la POO: t'as pas un vrai modele objet sans heritage...

J'utilise au maximum la composition dans mes projets a la place de l'heritage. L'heritage donne la plupart du temps du code illisible, on ne sait plus qui appelle quoi ni dans quel sens, et surtout c'est une plaie a maintenir, etant couple a mort a la classe mere.
Une chose tout de meme interessante a noter est que les DP utilisent enormement l'heritage d'implementation mais uniquement si la logique metier est peu importante (Adapter, Composite, State...) sans compter bien sur les frameworks Java et .Net qui l'utilisent aussi enormement. Mais la tout depend du contexte: dans le cas du design des api (ou des frameworks pour etre plus general) il est preferable d'utiliser les classes aux interfaces du fait justement de leur manque de flexibilite; une fois definie les membres de l'interface ne peuvent pas etre changes. On se tournera plus facilement vers les classes abstraites, mais j'aurais tendance a considerer le developpement de ces APIs comme un cas particulier.

Les interfaces je vois plus ca comme un moyen d'augmenter la separation des couches et le decouplage; ainsi il est tout a fait possible de ne manipuler que des interfaces et que tous les objets metiers implementent une interface; ca s'applique tres bien aux projets utilisant un outil de mapping OR, et ca evite ainsi d'etre dependant de l'implementation technique fournie par l'outil. Bien sur ca possede un inconvenient majeur, ca oblige a maintenir les interfaces en parallele des classes (et c'est pour ca que c'est pas conseille pour le developpement de frameworks).
Je rajouterai que l'heritage permet de definir "un type de", une interface definit une notion de capacite.

Pour ton exemple t'as plusieurs articles qui traitent de ca et il existe plusieurs solutions selon les exigences, je pense notammenent a la creation d'une classe role liee a la personne. 2 articles interessants a ce sujet, qui peuvent faire un peu mal a la tete :
-Dealing with Roles de Martin Fowler
-The Role Object Pattern

[FRED.G]

Une chose tout de meme interessante a noter est que les DP utilisent enormement l'heritage d'implementation mais uniquement si la logique metier est peu importante (Adapter, Composite, State...) sans compter bien sur les frameworks Java et .Net qui l'utilisent aussi enormement.

Je crois qu'on est tout à fait d'accord, c'est ce que j'avais essayé d'illustrer il me semble en prenant l'exemple des composants d'accès aux données... Mais comme tu l'as dit c'est le cas en général pour les API, et j'avais évoqué l'usage d'interface plutôt pour des objets métier.

D'ailleurs, j'ajoute que ma réflexion se fait justement dans le cadre d'une étude d'outil de mapping O/R... C'est pourquoi je crois que je te rejoins encore là dessus :

Les interfaces je vois plus ca comme un moyen d'augmenter la separation des couches et le decouplage; ainsi il est tout a fait possible de ne manipuler que des interfaces et que tous les objets metiers implementent une interface; ca s'applique tres bien aux projets utilisant un outil de mapping OR, et ca evite ainsi d'etre dependant de l'implementation technique fournie par l'outil.

Pour ce qui est des Design pattern, que je découvre, tout cela est encore très abstrait pour moi. J4ai du mal à assimiler ces notions sans exemples concrets.

[Maniak]

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é ?

Question bête : pourquoi est-ce que clients et employés *sont* des contacts ?
Je ne sais pas ce qu'il y a dans ta classe Contact, mais là comme ça j'aurais tendance à dire :
- Client a les infos de client d'un client
- Employe a les infos d'employé d'un employé
- Client a des infos de contact -> une instance de la classe Contact
- Employe a des infos de contact -> une instance de la classe Contact

Je ne vois pas vraiment de raison de faire d'héritage entre tout ça. Un client n'est pas un contact. Il contient des informations permettant de le contacter. Et là pour le coup, Client comme Employe (comme Contact) pourraient implémenter une interface IContact (ou IContactable) avec les propriétés/méthodes correspondantes. Dans le cas de Contact, ça correspondrait directement aux champs de la classe, dans le cas de Client et Employe, ce serait simplement redirigé à l'instance de Contact.

Tout ça pour dire que ce n'est pas une histoire d'héritage d'implémentation vs héritage d'interface, mais plutôt une histoire d'héritage vs composition.
L'utilisation des interfaces est un peu orthogonale à tout ça. Elles peuvent aider dans les cas de composition (cf ci-dessus), mais aussi dans les cas d'héritage (par exemple pour limiter l'accès à une partie des membres, cf IEnumerable). + tout ce qui est découplage, isolation des couches/librairies, switch d'implémentation à la demande (très pratique pour les tests unitaires), ... Pas grand chose à voir avec l'héritage.

Ce n'est pas non plus une histoire de design patterns. C'est une histoire de design tout court. Si tu m'expliques en quoi un client *est* un contact, et plus précisément ce qu'est au juste un contact (une personne ou un simple regroupement d'informations permettant de contacter une entité, sans pour autant la définir ?), peut-être qu'en faire une classe de base pour Client et Employe aura plus de sens :)


Sinon, tant que j'en suis à faire un roman (ça fait longtemps), ta question initiale est un peu bancale. Tu dis que Contact est la classe de base, avec Client et Employe en dérivés, et tu demandes comment modéliser un contact qui serait à la fois client et employé. C'est à l'envers là. Un contact n'est ni un client ni un employé. Un client est un contact, un employé est un contact, pas l'inverse. Et avec cette approche tu es coincé.
En revanche, si un client *a* un contact et qu'un employé *a* un contact, rien n'empêche un client *et* un employé d'*avoir* le même contact :)

Côté ORM/BDD, ça voudrait dire que tu aurais (par exemple) d'un côté tes clients, de l'autre tes employés et à côté de tout ça tes contacts, qui peuvent être utilisés (et partagés) par n'importe qui.
Selon ce que tu fais côté ORM, tu pourrais du coup à partir d'un objet Contact retrouver tous les clients & employés qui s'y réfèrent, *donc* avoir un contact lié à la fois à un (ou plusieurs) client(s) et à un (ou plusieurs) employé(s).

[FRED.G]

Je rajouterai que l'heritage permet de definir "un type de", une interface definit une notion de capacite.

Sur ce point je ne suis pas sûr d'être d'accord... C'est sans dout aussi un peu l'objet de ce débat : je ne vois pas pourquoi les interfaces ne permettraient permettent de définir "un type de" au même titre qu'une classe de base.

---------------

Bonjour Maniak, merci pour ta participation !

Si tu m'expliques en quoi un client *est* un contact, et plus précisément ce qu'est au juste un contact (une personne ou un simple regroupement d'informations permettant de contacter une entité, sans pour autant la définir ?), peut-être qu'en faire une classe de base pour Client et Employe aura plus de sens

Je considérais mon entité Contact comme une personne. On est donc bien dans la problématique de l'héritage. Je précise cependant que je partage ta façon de voir les choses pour le cas où Contact serait un regroupement d'infos permettant de contacter (cas *avoir* au lieu de *être*).

Pour essayer d'être plus précis, je propose de reprendre l'exemple disponible dans l'article de SQL pro sur la modélisation de l'héritage en SQL :

Pour comprendre l'intérêt de la modélisation par héritage, commençons par une application très banale qui devra contenir des prospects, des clients et des employés... Une gestion commerciale par exemple...

[Thomas Lebrun]

Personnellemement, je n'aime pas la modélisation qui est faite dans l'image en pièce jointe car avec elle, un employee ou un prospect ne peut pas être un client....

[FRED.G]

Si si !
Pourquoi dis-tu cela ?
L'héritage de ce modèle n'est pas exclusif. Sinon cela serait signalé par une petite croix dans le demi cercle qui lie les entités filles à la mère... (cf. exemple miniature jointe)

Décidément je ne sais plus comment faire pour poster un exemple clair pour tous !

[Thomas Lebrun]

Là, c'est plus clair déjà

[Maniak]

Je considérais mon entité Contact comme une personne. On est donc bien dans la problématique de l'héritage. Je précise cependant que je partage ta façon de voir les choses pour le cas où Contact serait un regroupement d'infos permettant de contacter (cas *avoir* au lieu de *être*).

Ben si tu passes en version *avoir*, le problème disparait non ? :)
Côté SQL ça ne change rien, c'est la même structure. Côté code, tu remplaces l'héritage par de la composition, et tu claques une interface au-dessus si besoin.

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.

Donc hop, une petite variation sémantique, tu gardes ta structure, tu utilises les interfaces pour spécifier les contrats des différentes classes, tu retires un niveau d'héritage et tu composes.

C'est à la fois un bon exemple de pourquoi l'héritage n'est pas la solution à tout et un bon exemple de design pris dans le mauvais sens. 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 :)