Quels motifs de conception en remplacement de l'héritage multiple ?

**Neuromancien2** · 27/02/2010, 19h42

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.

**Mac LAK** · 28/02/2010, 02h07

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...

**Neuromancien2** · 28/02/2010, 17h35

Envoyé par Mac LAK

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.

**Mac LAK** · 28/02/2010, 21h27

La composition EST un design pattern...

**Neuromancien2** · 01/03/2010, 01h22

Envoyé par Mac LAK

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...

**Mac LAK** · 01/03/2010, 01h55

Envoyé par Neuromancien2

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.

gl · 28/02/2010, 13h03

Envoyé par Neuromancien2

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)

**souviron34** · 22/06/2010, 11h54

Envoyé par Neuromancien2

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 bibliothèque de services ??

Ah.. Suis-je bête... !! Pas en objet

**MABROUKI** · 18/10/2010, 01h53

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.

**olivieram** · 12/06/2011, 06h58

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 - Visualiser dans une fenêtre à part

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.