Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Quels motifs de conception en remplacement de l'héritage multiple ?
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.
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...
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)Envoyé par Neuromancien2
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.
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.La composition EST un design pattern...
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...
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.
De toute façon, il me semble bien que les auteurs disent n'avoir rien inventé mais juste cataloguer les pratiques habituelles qu'ils avaient observées. Et qu'en gros, ils ont donné un nom à ce que déjà beaucoup de développeurs faisaient sans le nommer. 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".
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.
Parce que tu trouves vraiment que le Flyweight pattern, qui est pourtant sur le catalogue du GoF, est un pattern digne de ce nom, alors que 99% des dévs appellent ça simplement "programmation procédurale" ??
Si le but est de partager un comportement entre plusieurs classe, le DP strategy peut être une solution intéressante...
PS: Ce que j'adore personnellement dans les DP, c'est les nouveaux développeurs qui ont mis le nez dans le bouquin du Gof et qui voient des patterns partout.
Une patternite aigüe en soi ce n'est pas grave, sauf quand on commence à ajouter 6 classes juste pour éviter un bête switch. Je trouve que c'est impressionnant à quel point les "modes" peuvent amener l'overengineering, spécialement la volonté de sur-abstraction entre les couches.
En général, je plus gêné par un manque d'abstraction que par trop d'abstraction.
Sauf si cette dernière est très mal faite.
Ah ! Ca me rappelle la premiere fois ou je ne connaissait que Singleton. Et je vois des singletons partout pendant des mois
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.
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.
Se rapprocher de motifs de conception connus (ou moins connus) permet de discuter plus facilement, de clarifier les idées, d'effectuer des recherches.
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.
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...
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.
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.
Je vote aussi pour le paterne Décorateur
Perso, je voterais pour le paterne Décorateur.
Amitiés à tous.
Peut-etre aussi des possibilités du cotés l'AOP
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.
Perso, je voterais pour le paterne Décorateur.
Amitiés à tous.
une bibliothèque de services ??
Ah.. Suis-je bête... !! Pas en objet
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager