IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Débats sur le développement - Le Best Of Discussion :

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


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Membre averti

    Profil pro
    Inscrit en
    mai 2002
    Messages
    622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 622
    Points : 386
    Points
    386
    Par défaut 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.

  2. #2
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  3. #3
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 165
    Points : 4 635
    Points
    4 635
    Par défaut
    Citation Envoyé par Neuromancien2 Voir le message
    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)

  4. #4
    Membre averti

    Profil pro
    Inscrit en
    mai 2002
    Messages
    622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 622
    Points : 386
    Points
    386
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    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.

  5. #5
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    La composition EST un design pattern...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  6. #6
    Membre averti

    Profil pro
    Inscrit en
    mai 2002
    Messages
    622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 622
    Points : 386
    Points
    386
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    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...

  7. #7
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par Neuromancien2 Voir le message
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  8. #8
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 634
    Points : 13 015
    Points
    13 015
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    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.
    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.

  9. #9
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    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".
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  10. #10
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2004
    Messages : 2 493
    Points : 4 100
    Points
    4 100
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    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.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  11. #11
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par Hephaistos007 Voir le message
    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" ??
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  12. #12
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 739
    Points
    7 739
    Par défaut
    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.

  13. #13
    Membre émérite
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 2 542
    Points
    2 542
    Par défaut
    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.

  14. #14
    Membre habitué Avatar de rakakabe
    Développeur informatique
    Inscrit en
    août 2007
    Messages
    124
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2007
    Messages : 124
    Points : 174
    Points
    174
    Par défaut
    Ah ! Ca me rappelle la premiere fois ou je ne connaissait que Singleton. Et je vois des singletons partout pendant des mois

  15. #15
    Membre averti

    Profil pro
    Inscrit en
    mai 2002
    Messages
    622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2002
    Messages : 622
    Points : 386
    Points
    386
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    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.
    Citation Envoyé par Mac LAK Voir le message
    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".
    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.

  16. #16
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2004
    Messages : 2 493
    Points : 4 100
    Points
    4 100
    Par défaut
    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.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  17. #17
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  18. #18
    Membre à l'essai
    Profil pro
    Développeur informatique
    Inscrit en
    février 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2003
    Messages : 12
    Points : 16
    Points
    16
    Par défaut Je vote aussi pour le paterne Décorateur
    Perso, je voterais pour le paterne Décorateur.

    Amitiés à tous.

  19. #19
    Membre à l'essai
    Profil pro
    Développeur informatique
    Inscrit en
    février 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2003
    Messages : 12
    Points : 16
    Points
    16
    Par défaut 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.

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

    Amitiés à tous.

  20. #20
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 65
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    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

    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

Discussions similaires

  1. Motif de conception
    Par pitchu dans le forum Android
    Réponses: 0
    Dernier message: 28/04/2015, 23h42
  2. objet 3d animé dans une scène, quel est le concept
    Par ShinobiX1 dans le forum Unity
    Réponses: 4
    Dernier message: 07/01/2014, 11h06
  3. [Décorateur] [Java] Quel modele de conception choisir au lieu de l'heritage ?
    Par Xiao-An dans le forum Design Patterns
    Réponses: 18
    Dernier message: 18/02/2007, 00h31
  4. quel type de conception pour un serveur?
    Par hisoka dans le forum Développement
    Réponses: 2
    Dernier message: 17/11/2006, 20h47
  5. [Conception] en remplacement de fopen
    Par Skeud007 dans le forum PHP & Base de données
    Réponses: 37
    Dernier message: 05/10/2006, 16h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo