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

Design Patterns Discussion :

Quels sont les avantages de l'utilisation d'interfaces ?


Sujet :

Design Patterns

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    17
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 17
    Points : 10
    Points
    10
    Par défaut Quels sont les avantages de l'utilisation d'interfaces ?
    Bonsoir à tous,

    Je viens du monde C++ et j'ai récemment étudié d'autres langages qui utilisent la notion d'interface

    J'ai tout d'abord compris cette notion comme étant un moyen de réunir plusieurs classes indépendantes (Ex : Homme et Felin)
    On factorise un comportement commun par le biais d'une interface.

    Cependant, j'observe souvent l'utilisation des interfaces comme une relation d'héritage "is-a". Or, pour cette relation, on utilise normalement naturellement l'héritage

    Au delà de la factorisation des comportements et de l'obligation d'adherer au contrat lorsqu'on implémente une interface, quels sont les autres utilités de l'interface

    Je poste dans cette catégorie en considérant que cette question est proche des "best practices"

    Merci d'avance pour vos informations

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 203
    Points : 36 631
    Points
    36 631
    Par défaut
    Bonsoir,

    J'ai tout d'abord compris cette notion comme étant un moyen de réunir plusieurs classes indépendantes (Ex : Homme et Felin)
    On factorise un comportement commun par le biais d'une interface.
    Côté pattern de conception, j'appellerai plutôt cela façade, adapter ou wrapper...

    Cependant, j'observe souvent l'utilisation des interfaces comme une relation d'héritage "is-a". Or, pour cette relation, on utilise normalement naturellement l'héritage
    A mon sens cela est sans doute spécifique à Java qui ne permet pas (comme C++ par exemple) des héritages multiples et pour lequel le concept d'interface peut être utilisé pour pallier cela.
    -W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  3. #3
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    cela est sans doute spécifique à Java qui ne permet pas (comme C++ par exemple) des héritages multiples et pour lequel le concept d'interface peut être utilisé pour pallier cela.
    +1 pour l'héritage multiple. Mais une interface peut aussi être utilisée pour remplacer l'héritage par la composition (''HAS-A'' plutôt que ''IS-A'') pour spécialiser un objet. Ce qui permet de réduire fortement le couplage entre les classes.

  4. #4
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 758
    Points : 2 085
    Points
    2 085
    Par défaut
    Citation Envoyé par TheLeadingEdge Voir le message
    +1 pour l'héritage multiple. Mais une interface peut aussi être utilisée pour remplacer l'héritage par la composition (''HAS-A'' plutôt que ''IS-A'') pour spécialiser un objet. Ce qui permet de réduire fortement le couplage entre les classes.
    Exactement, d'où le terme d'interface - de communication. CQFD.
    C'est pour moi le principal intérêt.

  5. #5
    Membre régulier

    Inscrit en
    Octobre 2006
    Messages
    30
    Détails du profil
    Informations forums :
    Inscription : Octobre 2006
    Messages : 30
    Points : 86
    Points
    86
    Par défaut
    Citation Envoyé par Blowdi Voir le message
    Cependant, j'observe souvent l'utilisation des interfaces comme une relation d'héritage "is-a". Or, pour cette relation, on utilise normalement naturellement l'héritage
    Je pense qu'il faut plutôt voir une interface comme is-ableof, elle définit l'enveloppe de tes futures implémentations en définissants des comportements.
    Par exemple si tu as des objets qui vont se dessiner dans une application tu vas définir une interface Drawable avec une méthode draw. L'utilisateur de Drawable n'a pas besoin d'en connaitre plus, les producteurs de Drawable eux seul connaitront la ou les implémentations. Et éventuellement dans le but de factoriser du code pourront avoir une notion d'héritage pour les objets circulaires par exemple. Si cette notion de circularité interesse quelqu'un d'autre que le producteur? -> INTERFACE!

    En phase de conception pour etre extreme tu ne vas définir que des interfaces sauf pour des objets qui representent de la donnée pure (des objets avec des attibuts et des getters/setters aussi appelés java bean mais ne font aucun traitement).

    Enfin l'avantage d'utiliser des interfaces va etre la capacité que tu auras de remplacer les implémentations finales par des implementations de tests ou "bouchons" pour tester une partie de ton application sans qu'une autre partie dont elle dépend (par l'interface) n'éxiste encore.

    Enfin une remarque non argumentée mais totalement empirique provenant de mon expérience de JAVA: L'héritage n'est à utiliser qu'en cas d'extrême urgence!! ;-)

    Ayant fait un tout petit peu d'Objective-C j'ai trouvé très interessant le principe de dire: Toute instance doit avoir son interface associée et personne ne voit l'implementation mais l'interface.

  6. #6
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,


    Je rajouterais juste une remarque : les interfaces et la notion d'abstraction complète de l'implémentation permettent d'éviter les problèmes de l'héritage en losange.

    Car une des grosses différences dans l'approche "orienté objet" de Java par rapport à C++ vient du fait que toutes les méthodes sont virtuelles par défaut, ce qui amplifie le risque de conflit lié à l'héritage multiple.

    a++

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    17
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2008
    Messages : 17
    Points : 10
    Points
    10
    Par défaut
    Je pense qu'il faut plutôt voir une interface comme is-ableof, elle définit l'enveloppe de tes futures implémentations en définissants des comportements.
    Effectivement, je vois le principal intérêt des interfaces comme un rajout de capacité peut importe le type

    Exemple : Une classe de connexion à une base de données est "Debugable" (implémente l'interface Debug) et une classe d'affichage d'images est aussi "Debugable". Les deux classes peuvent êtres traitées indifféremment par le biais de cette interface

    Mais une interface peut aussi être utilisée pour remplacer l'héritage par la composition (''HAS-A'' plutôt que ''IS-A'') pour spécialiser un objet. Ce qui permet de réduire fortement le couplage entre les classes.
    Dans le livre "Design pattern Tête la première", cette notion de composition est mise en avant dans l'explication du pattern "Strategy". Cette notion de HAS-A permet de greffer dynamiquement des comportements aux classes.

    Arrêtez moi si je me trompe ;-)

  8. #8
    Membre expérimenté
    Profil pro
    Inscrit en
    Février 2004
    Messages
    1 824
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 1 824
    Points : 1 544
    Points
    1 544
    Par défaut
    Ta question revient à "A quoi sert le polymorphisme"

    Fait des recherches là dessus

    Attention : Il y a plusieurs types de polymorphisme, le dynamique (avec des interfaces ou des classes abstraites) et le statique (avec les templates, les classes politiques etc.)
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  9. #9
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    Arrêtez moi si je me trompe ;-)
    Non, non. C'est bon. Mais je pensais plutôt à la délégation, une classe ''à la capacité de'' (is able of comme l'a dit qqu'un ci-dessus) ou au décorateur.
    Le DP Strategie est un bon exemple d'utilisation de l'interface en OOA.
    même si pour moi il reste plutôt proche de l'héritage (sans certaines de ses contraintes).

  10. #10
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Avril 2006
    Messages : 51
    Points : 64
    Points
    64
    Par défaut
    J'ajouterais que pendant un bon moment en Java notamment, on utilisait énormément d'interfaces (pour une classe java, il y a une interface (au moins)). Aujourd'hui la tendance est plutôt de revenir en arrière et de n'utiliser les interface quand cela s'avère nécessaire (et là c'est du design):
    on veut séparer les contrats pour une seule implémentation
    on veut avoir plusieurs implémentations
    on ne veut exposer qu'une partie des contrats au code client
    on veut livrer un jar d'API à un client externe
    ...

    Bref l'idée est de ne pas mettre une interface quand il n'y a pas de raison d'en mettre, si jamais il y en a besoin alors il faudra faire un refactoring. Ce n'est pas gênant parce que le besoin évolue donc le code sera à modifier de toute façon.

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 203
    Points : 36 631
    Points
    36 631
    Par défaut houla!
    J'ai l'impression que la discussion mélange deux domaines assez différents que sont:

    - les patterns de collaboration entre objets dans lesquels les glues facade, adapter, wrapper, strategy proposent des variantes à adapter à son cas particulier

    - interface offerte par un composant style l'API d'une DLL (pour sortir de l'interface Java qui est assez particulière).

    L'interface est proche de la façade: les choses se passent derrière l'API et son client n'a pas à se soucier de l'implémentation. Mieux, on peut changer le composant et pourvu que l'API soit respectée, le client est servi de la même façon (en principe).

    Tout çà pour dire que 'interface' comme porte pour communiquer avec un composant (quelqu'il soit) n'a pas grand chose a voir à priori avec la construction de liens entre objets (qui traite de la construction du composant).
    -W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  12. #12
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 203
    Points : 36 631
    Points
    36 631
    Par défaut
    Citation Envoyé par TheLeadingEdge Voir le message
    +1 pour l'héritage multiple. Mais une interface peut aussi être utilisée pour remplacer l'héritage par la composition (''HAS-A'' plutôt que ''IS-A'') pour spécialiser un objet. Ce qui permet de réduire fortement le couplage entre les classes.
    Honnêtement, je ne connais pas de pattern de structuration qui s'appelle 'interface pattern'... Or le but de ces patterns est justement de réduire le couplage induit par l'héritage.

    Et dans le fil de la discussion, on voit bien que 'interface' se rapporte à un ensemble de pattern de structuration...
    Certes, on va pouvoir mettre des interface dans la plupart de ces patterns écrits en Java... Mais n'est-ce pas spécifique a une mise en œuvre Java?
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  13. #13
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    Honnêtement, je ne connais pas de pattern de structuration qui s'appelle 'interface pattern'...
    Or le but de ces patterns est justement de réduire le couplage induit par l'héritage.
    Et dans le fil de la discussion, on voit bien que 'interface' se rapporte à un ensemble de pattern de structuration...
    Si on parle bien de la même chose, E. Gamma à classé Décorateur dans les patterns structurels.
    Mais Stratégie est un pattern comportemental (tjours selon Gamma).
    Je pense que les DP peuvent servir d'exemples ponctuellement, mais que circonscrire le concept d'interface à un ou plusieurs patterns est une fausse piste. C'est un concept beaucoup plus général.

    Certes, on va pouvoir mettre des interface dans la plupart de ces patterns écrits en Java...
    Mais n'est-ce pas spécifique a une mise en œuvre Java?
    J'avoue pour Java. Et aussi que je suis vraiment rouillé en C+. Mais on peut remplacer interface (java) par classe abstraite (c++) ?
    C'est toujours le même concept ''développer pour une interface, pas pour une implémentation''.

  14. #14
    Futur Membre du Club
    Inscrit en
    Novembre 2006
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : Novembre 2006
    Messages : 9
    Points : 7
    Points
    7
    Par défaut
    Citation Envoyé par TheLeadingEdge Voir le message
    C'est toujours le même concept ''développer pour une interface, pas pour une implémentation''.
    Oui, déjà il est conseillé de mettre toujours le nom de l'interface à gauche puis reste à voir comment on va instancier l'objet (designs patterns créationnels comme l'AbstractFactory, instancier directement l'objet....)

  15. #15
    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 017
    Points
    13 017
    Par défaut
    Bonjour,
    De prime abord, j'aurais tendance à définir une interface en C++ comme une classe abstraite cad dont toutes les fonctions sont virtuelles pures. C'est une relation IS-A dans le sens où la classe concrète met en œuvre l'interface définie.
    A quoi ça sert ? Ben à abstraire le contrat définit par l'interface des détails d'implémentation proposés par la classe concrète.

  16. #16
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 203
    Points : 36 631
    Points
    36 631
    Par défaut
    Citation Envoyé par TheLeadingEdge Voir le message
    J'avoue pour Java. Et aussi que je suis vraiment rouillé en C+. Mais on peut remplacer interface (java) par classe abstraite (c++) ?
    C'est toujours le même concept ''développer pour une interface, pas pour une implémentation''.
    Cela ne revient-il pas à comparer une "feature" Java avec sa réalisation en C++? Quel est le Design Pattern associé a cette 'feature' ?
    -W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  17. #17
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Août 2007
    Messages
    44
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2007
    Messages : 44
    Points : 28
    Points
    28
    Par défaut avis de néophyte
    Bonjour, et tout d'abord merci pour cette discussion qui m'éclaire sur l'utilité des interfaces.

    J'utilise ce concept avec Zope3, et j'avoue avoir du mal à cerner non le rôle des interfaces (contrat, ...) mais leur utilité dans un projet. Sans doute parce que mes applis (enfin, mes essais d'applis) n'ont pas le volume suffisant : je subis le concept au lieu de l'utiliser vraiment.

    A ce jour, l'intérêt principal que je trouve à mes interfaces, c'est de structurer la doc correctement : comme c'est incontournable, je suis bien obligé de rédiger un minimum de doc. Par ailleurs, cela me permet de comprendre les interfaces des autres, ce qui n'est pas négligeable ! Les projets Zope 3 sont systématiquement documentés, et ça aide !

    A bientôt

    JMarc

  18. #18
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 203
    Points : 36 631
    Points
    36 631
    Par défaut Zope
    Zope est un monde à lui tout seul.
    Les interfaces vis à vis des composants sont découvertes par introspection - en fait c'est écrit en Python, langage dynamique s'il en est.
    Je ne sais pas si les motivations de ce que nous avons raconté ici peuvent s'appliquer à un tel monde.
    Note: Les soucis à résoudre lorsqu'on fait des composants avec du langage compilé sont identiques. Mais le 'dynamique' permet de lier les objets de façon assez originale et facile.
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

Discussions similaires

  1. Quels sont les avantages d'utiliser CUDA dans le développement de jeux?
    Par geektoo dans le forum Développement 2D, 3D et Jeux
    Réponses: 2
    Dernier message: 20/02/2015, 19h27
  2. Réponses: 7
    Dernier message: 05/09/2011, 15h42
  3. Réponses: 2
    Dernier message: 14/01/2006, 12h19
  4. Réponses: 3
    Dernier message: 12/08/2005, 10h14
  5. Quels sont les avantages de dériver d'un TComponent ?
    Par WebPac dans le forum Composants VCL
    Réponses: 17
    Dernier message: 18/03/2005, 10h07

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