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

Le , par Neuromancien2, Membre averti
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.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Mac LAK Mac LAK - Inactif http://www.developpez.com
le 10/03/2010 à 15:36
Citation Envoyé par Neuromancien2  Voir le message
Une approche considérée comme une bonne réponse à un problème courant et que l'on peut réutiliser est un modèle de conception. Cela ne se limite pas aux 23 design patterns du GOF.

Vœu pieux... Beaucoup sont persuadés que ces 23 DP sont non seulement la seule voie possible, mais qu'en plus, ils sont exhaustifs.
Et, avec ta définition, la composition est bien un DP : c'est une bonne réponse, et c'est réutilisable...

Citation Envoyé par Neuromancien2  Voir le message
Les termes "motif de conception" et "héritage multiple" ne vous plaisent pas... Oublions les un instant. Ce que je voulais faire c'est lancer une discussion sur les différentes approches pour ajouter des fonctionnalités à des classes en réutilisant le code. Je suis surpris de certaines réactions car je pensais que, independamment des termes utilisés, cette discussion pourrait intéresser beaucoup de monde.

Disons qu'il faudrait repartir sur la question initiale, qui était "comment remplacer l'héritage multiple quand le langage ne le permet pas". La bonne réponse est "composition et interfaces", suivant les possibilités du langage, mais on reste plus ou moins dans le domaine du statique (résolu à la compilation).

Si, par contre, ta question porte sur l'ajout DYNAMIQUE (pendant l'exécution) de fonctionnalités à une classe (un peu dans le genre "plug-in", donc), alors on arrive dans une toute autre problématique. Il te faut dans ce cas voir du côté des patterns Visitor, Decorator et Strategy, sachant que leur implémentation peut être extrêmement différente d'un langage à l'autre. Mais implémenter ça pour résoudre un problème statique est du pur masochisme.

Citation Envoyé par Neuromancien2  Voir le message
Se rapprocher de motifs de conception connus (ou moins connus) permet de discuter plus facilement, de clarifier les idées, d'effectuer des recherches.

En théorie, oui. En pratique, la plupart des développeurs sont fortement influencés par leur langage de prédilection, ce qui modifie fortement leur perception d'un DP donné.

Par exemple, une Factory est quelque chose d'élémentaire (voire trivial) dans un langage possédant des capacités d'introspection/réflexion, notamment les langages interprétés. En C++, c'est déjà moins évident à faire.

C'est un peu pour ça que j'ai tendance à éviter d'être TROP abstrait dans l'utilisation des patterns : suivant le langage d'implémentation, c'est du boulot trivial ou le pire piège possible. Du coup, rester "uniquement" dans le monde des "DP bisounours" implémentables dans tous les langages sans notion de surcoût peut devenir dangereux pour un projet.
Avatar de BugBlaster BugBlaster - Membre à l'essai http://www.developpez.com
le 21/06/2010 à 21:59
Perso, je voterais pour le paterne Décorateur.

Amitiés à tous.
Avatar de BugBlaster BugBlaster - Membre à l'essai http://www.developpez.com
le 21/06/2010 à 22:20
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).

Plus d'infos :
http://laurent-dardenne.developpez.c...mework/Aspect/

Amitiés à tous.

Citation Envoyé par BugBlaster  Voir le message
Perso, je voterais pour le paterne Décorateur.

Amitiés à tous.

Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 22/06/2010 à 10:54
Citation Envoyé par Neuromancien2  Voir le message
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

Avatar de davcha davcha - Membre expérimenté http://www.developpez.com
le 22/06/2010 à 13:09
Citation Envoyé par BugBlaster  Voir le message
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.
Avatar de MABROUKI MABROUKI - Membre émérite http://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.
Avatar de olivieram olivieram - Inactif http://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.
Avatar de javan00b javan00b - Membre actif http://www.developpez.com
le 15/06/2011 à 2:43
Le strategy pattern utilise la composition et la delegation et elimine habituellement les problemes les plus simple d`heritage multiples.
Avatar de Hephaistos007 Hephaistos007 - Membre expert http://www.developpez.com
le 15/06/2011 à 13:53
Citation Envoyé par javan00b  Voir le message
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...
Avatar de javan00b javan00b - Membre actif http://www.developpez.com
le 15/06/2011 à 19:43
Citation Envoyé par Hephaistos007  Voir le message
Ç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é.
Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 16/06/2011 à 1:50
Citation Envoyé par javan00b  Voir le message
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 ...
Offres d'emploi IT
Consultant technique éditeur logiciel h/f
Florian Mantione Institut - Languedoc Roussillon - Montpellier (34000)
H/F Développeur logiciel expérimenté
Index Education - Provence Alpes Côte d'Azur - Marseille (13000)
Projet de la bu sap
Atos - Ile de France - Bezons (95870)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Pascal : Gilles Vasseur - Alcatîz -