Discussion :

[davcha]

Il y a peut-être aussi des possibilités cotés programmation Orienté Aspect.

Après, tout dépend de la manière, tant que cela reste dynamique me ca va (facile en .net ou en delphi si on a fait un peu de Com), a fuir s'il faut s'embarquer sur du statique (remplissage de xml+générateur de code).

Tu peux faire ça en statique, sans passer par des générateurs de code et du xml.

Il existe plusieurs bibliothèques qui font ça en .NET et en Java, par exemple, sans passer par du xml et de la génération de code.

La plupart du temps, il s'agit plutôt de manipulation de bytecode.

[MABROUKI]

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]

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.

[javan00b]

Le strategy pattern utilise la composition et la delegation et elimine habituellement les problemes les plus simple d`heritage multiples.

[Hephaistos007]

Le strategy pattern utilise la composition et la delegation et elimine habituellement les problemes les plus simple d`heritage multiples.

Ça n'a aucun rapport...

[javan00b]

Ça n'a aucun rapport...

La question initiale de 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. 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.

je dis seulement que dans certain cas un simple strategy pattern peut rendre l'utilisation de l'heritage multiple totalement inutile. pourquoi ? parce que beaucoup de developpeurs abusent de l'heritage multiple systematiquement parce qu'ils ne connaissent rien d'autres.

Rare sont les cas utilisations d'heritage multiple justifié.

[souviron34]

Rare sont les cas utilisations d'heritage multiple justifié.

bien que ne pratiquant pas de langages où c'est présent, je suis obligé d'admettre que le nombre de fois où je vois avancer l'héritage multiple comme argument ou comme "construction" est effarant.... par rapport à mon expérience où je n'en pas vraiment vu la pertinence de toute ma carrière (même en prenant des choses très objets comme les IHM...)

Je pense que c'est un biais (encore) de l'enseignement de l'objet, et simplement un manque d'analyse ...