Developpez.com - Rubrique Pascal

Le Club des Développeurs et IT Pro

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

Pour les langages ne le supportant pas ?

Le 2010-02-27 18:42:37, 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.
  Discussion forum
26 commentaires
  • Mac LAK
    Inactif
    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...
    le 28/02/2010 à 1:07
  • gl
    Rédacteur
    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)
    le 28/02/2010 à 12:03
  • Neuromancien2
    Membre averti
    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...
    le 01/03/2010 à 0:22
  • Mac LAK
    Inactif
    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.
    le 01/03/2010 à 0:55
  • Mac LAK
    Inactif
    Envoyé par 3DArchi
    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".
    le 01/03/2010 à 16:07
  • Hephaistos007
    Expert confirmé
    Envoyé par Mac LAK
    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.
    le 01/03/2010 à 21:19
  • Hephaistos007
    Expert confirmé
    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.
    le 10/03/2010 à 15:01
  • MABROUKI
    Expert confirmé
    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.
    le 18/10/2010 à 0:53
  • olivieram
    Inactif
    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 : 
    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.
    le 12/06/2011 à 5:58
  • Neuromancien2
    Membre averti
    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.
    le 28/02/2010 à 16:35
  Poster une réponse