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

[0xYg3n3]

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

Sans doute en jettant un oeil du côté des design pattern.

[dev01]

Sans doute en jettant un oeil du côté des design pattern.

lequel ? c'est ma question ... Des design pattern il y en a plein, si tu peux argumenter un peu plus que simplement : les design pattern ... ça serait pas mal

[The_badger_man]

si tu peux argumenter un peu plus que simplement : les design pattern ... ça serait pas mal

Arrête, design pattern ça fait stylé, ya pas besoin d'argumenter

[dev01]

Arrête, design pattern ça fait stylé, ya pas besoin d'argumenter

[0xYg3n3]

Des design pattern il y en a plein, si tu peux argumenter un peu plus que simplement : les design pattern

Ca me fait penser a un exmple que j'ai lu dans un livre dédié au design pattern.
L'exemple des canards.

Des canards "vivants", des canards en "plastique".
Des canards qui volent (vivants)
Des canards qui cancanent (vivants et plastique)

Comme tu l'as dit il existe beaucoup de design pattern.

Après en ayant 22 ou 23 ans (cf vos profils) on a pas du rencontrer beaucoup de cas "tordu".
Mais heureusement d'autres personnes l'ont rencontré et mettent a disposition leur solution.

Elle est grande notre communauté.

[Thomas Lebrun]

Mais heureusement d'autres personnes l'ont rencontré et mettent a disposition leur solution.

Ce qui ne semble pas être ton cas

Depuis le début, tu ne sembles connaitre que ce mot: "design pattern" et lorsque l'on te demande de te justifier, tu ne fais que reprendre un exemple similaire à celui donné par FRED.G.

Il est intéressant de savoir affirmer des choses mais il est encore plus intéressant de savoir se justifier correctement le moment venu....


Bref, pour conclure:
Tu as la réponse à la question ? Alors poste là au lieu de tourner autour du pot. Tu ne connais pas cette solution, alors abstiens-toi de répondre et de critiquer les communautés

[dev01]

Après en ayant 22 ou 23 ans (cf vos profils) on a pas du rencontrer beaucoup de cas "tordu".

Je vois ce que mon age vient faire la dedans . Je vais étaler ma vie mais des cas tordu j'en ai rencontré .... Je passe sur les détails.

Pour le reste, Thomas Lebrun a très bien exprimé ce que je pense ...

[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

[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" ?

[davcha]

La problématique d'avoir un objet d'un type donné qui puisse "devenir" un autre type dérivé de la classe mère du type de l'objet ?

DP State ?