IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quels motifs de conception en remplacement de l'héritage multiple
Pour les langages ne le supportant pas ?

Le , par Neuromancien2
26 commentaires

39PARTAGES

1  0 
Bonjour,

De nombreux langage orientés objet ne supportent pas l'héritage multiple (Java, PHP, Pascal...). Or a on souvent besoin d'ajouter des fonctionnalités à un objet en réutilisant du code. Quels motifs de conception peut-on utiliser dans ce cas ? Le motif Décorateur est très intéressant mais ne peut pas être utilisé dans tous les cas.

Une erreur dans cette actualité ? Signalez-nous-la !

26 commentaires
Commenter Signaler un problème
Mac LAK
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 28/02/2010 à 1:07
Tu peux utiliser la composition, ou les interfaces si le langage le permet.

A titre strictement personnel, j'ai plutôt tendance à penser qu'un héritage multiple est une erreur de conception : c'est souvent le signe d'un "mélange" de code qui n'est souvent pas souhaitable et qui pose encore plus souvent des problèmes de maintenabilité.

Pour tout ce que j'ai pu voir en héritage multiple en dix ans d'expérience, j'ai hélas toujours eu raison : ce fut à chaque fois une usine à gaz infernale à maintenir, et une source de régressions assez violente...
3  0 
gl
Avatar de gl
Rédacteur https://www.developpez.com
Le 28/02/2010 à 12:03
Citation Envoyé par Neuromancien2 Voir le message
De nombreux langage orientés objet ne supportent pas l'héritage multiple (Java, PHP, Pascal...). Or a on souvent besoin d'ajouter des fonctionnalités à un objet en réutilisant du code.
Si c'est uniquement dans le but de réutiliser du code (et donc hors du cadre d'une relation EST-UN entre les deux objets), je privilégierais la composition (y compris dans les langages supportant l'héritage multiple d'ailleurs)
2  0 
Neuromancien2
Avatar de Neuromancien2
Membre averti https://www.developpez.com
Le 01/03/2010 à 0:22
Citation Envoyé par Mac LAK Voir le message
La composition EST un design pattern...
Pas pour moi. C'est un terme générique désignant différentes formes d'associations entre classes.
Mais je suppose qu'ici vous faites référence au delegate pattern, qui combiné à l'utilisation d'interfaces permet de réutiliser du code provenant de différentes classes. Mais l'implémentation reste assez lourde...
2  0 
Mac LAK
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 01/03/2010 à 0:55
Citation Envoyé par Neuromancien2 Voir le message
Pas pour moi. C'est un terme générique désignant différentes formes d'associations entre classes.
Mais je suppose qu'ici vous faites référence au delegate pattern.
Attention, ce qui suit n'est en aucune manière une attaque personnelle, juste un constat général...

Il faut arrêter de se gargariser avec des termes "à la mode" juste pour faire joli dans les revues de conception. Je te rappelle que design pattern, ça veut juste dire modèle de conception, et pas autre chose.

Quand ce terme de "design pattern" est devenu à la mode, je me suis rendu compte que la plupart d'entre eux m'étaient non seulement connus, mais qu'en plus je les appliquait déjà depuis des années (quand je ne les avais pas "réinventés" moi-même, comme les décorateurs, les ponts, les adaptateurs (wrappers), les singletons, les fabriques ou encore les observateurs...). Simplement, je n'avais pas le "nom à la mode" à mettre dans ma doc de conception.

J'ai aussi remarqué que beaucoup de gens utilisant ces termes ne savent en fait pas les appliquer : ils suivent une doc, mais ne comprennent pas réellement ce qu'il y a derrière et/ou font une usine à gaz d'un truc finalement très simple. J'ai constaté la même chose avec la méthodologie MDA et DDA, d'ailleurs : c'est toujours marrant de dire qu'un simple batch est un "programme en technologie MDA", juste parce qu'il génère des éléments complexes depuis un ensemble d'éléments simples...

Enfin, il faut arrêter de croire qu'il n'existe "que" 23 manières d'implémenter quelque chose : c'est en fait bien plus vaste que ça, et tout dépend des contraintes métier et/ou techniques... Après, on peut toujours se raccrocher à un des 23 GoF, mais parfois, cela frise le ridicule de faire ça (genre le Flyweight pattern, qui s'applique en gros à toute la programmation procédurale "classique".

Donc, je te le redis : la composition EST un modèle de conception (ou "design pattern" tout à fait valide et normal, à toi de voir comment l'implémenter après : en fonction de tes classes, cela peut être (et pour utiliser les termes qui te parleront un peu plus) du Delegate, du Composite, ou même du Decorator... Tout dépend du niveau de proximité des deux classes que tu dois composer.
3  1 
Mac LAK
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 01/03/2010 à 16:07
Citation Envoyé par 3DArchi Voir le message
Sommes toutes, c'est aussi un gros avantage de partager le même vocabulaire pour des choses similaires. Ca facilite la transmission et la maintenance.
Je suis bien d'accord avec toi, mais parfois, ça frise le ridicule... On sent bien que certains (et non, je ne vise personne ayant participé à ce sujet) se servent de ces termes "à la mode" sans savoir ce que cela recouvre, ou en les implémentant façon "usine à gaz".
2  0 
Hephaistos007
Avatar de Hephaistos007
Expert confirmé https://www.developpez.com
Le 01/03/2010 à 21:19
Citation Envoyé par Mac LAK Voir le message
Je suis bien d'accord avec toi, mais parfois, ça frise le ridicule... On sent bien que certains (et non, je ne vise personne ayant participé à ce sujet) se servent de ces termes "à la mode" sans savoir ce que cela recouvre, ou en les implémentant façon "usine à gaz".
Je plussoie.

Pour autant, je ne suis pas d'accord avec toi sur le coup de la composition. La notion de composition est, au même titre que la spécialisation, un concept inhérent au paradigme objet (depuis les années 80). Ainsi, ni la composition, ni la spécialisation ne peuvent être qualifiés de patterns, au sens ou il ne fournissent pas de solution à un problème donné dans un contexte (cf. la définition d'un pattern). De même, je suis personnellement contre le "pattern" délegate, qui n'en est pas un (je vois mal quel est le contexte et quelle est la solution décrite). D'ailleurs, il n'appartient pas au catalogue du GOF. Au mieux, c'est un idiome.
2  0 
Hephaistos007
Avatar de Hephaistos007
Expert confirmé https://www.developpez.com
Le 10/03/2010 à 15:01
Le pattern décorateur est effectivement bien approprié (qui est basé sur la composition). Sinon, il y a interface + composition en "remplacement" de l'héritage multiple.
2  0 
MABROUKI
Avatar de MABROUKI
Expert confirmé https://www.developpez.com
Le 18/10/2010 à 0:53
La seule alternative à l'heritage multiple actuellement c'est :
- les design pattern "DELEGATE" & "INTERFACE"
Avantage de cette methode :
- les parties de code sont indepentantes les unes des autres.
- possibilite de reutilisation plus vaste du code comme dans le cas de l'heritage(hors du cadre d'une classe ou d'un projet) .
- tout avantage se paye -le pattern "DELEGATE" et particulierement
"INTERFACE" necessite de reecrire du code d'implementation specifique a chaque objet.
2  0 
olivieram
Avatar de olivieram
Inactif https://www.developpez.com
Le 12/06/2011 à 5:58
Bonjour,
Sans vouloir détacher ce débat sur l'héritage multiple, je pense qu'au moins en C#, les extensions de méthodes sont une alternative à l'héritage multiple.
Alors, c'est peut-être compliqué à comprendre, mais je vais juste donner un petit exemple en C#.
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
class A {
  public void Start(int) { ... }
  public void End(int) { ... }
}
class ExtA {
  public static Interrupt(this A process, int i) { ... }
  public static Resume(this A process, int i) { ... }
}
C'est un peu comme si A héritait d'une nouvelle interface. Pourtant, on n'a rien modifié dans le code de A.
2  0 
Neuromancien2
Avatar de Neuromancien2
Membre averti https://www.developpez.com
Le 28/02/2010 à 16:35
Citation Envoyé par Mac LAK Voir le message
Tu peux utiliser la composition, ou les interfaces si le langage le permet.
Oui je sais bien qu'il faudra utiliser la composition, mais il y a différentes approches possibles. L'utilisation des interfaces ne résoud pas à elle seule le problème. Je réfléchis donc aux design patterns à utiliser pour réutiliser du code de manière simple et élégante.
1  0 
Commenter Signaler un problème