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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Conception : Quels sont les avantages de l'utilisation d'interfaces
En analyse orientée objet ?

Le , par Blowdi
17 commentaires

22PARTAGES

0  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

17 commentaires
Commenter Signaler un problème
wiztricks
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 06/10/2009 à 21:19
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
0  0 
TheLeadingEdge
Avatar de TheLeadingEdge
Membre expert https://www.developpez.com
Le 06/10/2009 à 21:50
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.
0  0 
blbird
Avatar de blbird
Membre chevronné https://www.developpez.com
Le 06/10/2009 à 23:12
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.
0  0 
pip1000
Avatar de pip1000
Membre régulier https://www.developpez.com
Le 07/10/2009 à 8:32
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.
0  0 
adiGuba
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/10/2009 à 9:09
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++
0  0 
Blowdi
Avatar de Blowdi
Membre à l'essai https://www.developpez.com
Le 07/10/2009 à 10:39
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 ;-)
0  0 
mister3957
Avatar de mister3957
Membre expérimenté https://www.developpez.com
Le 07/10/2009 à 12:00
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.)
0  0 
TheLeadingEdge
Avatar de TheLeadingEdge
Membre expert https://www.developpez.com
Le 07/10/2009 à 12:31
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).
0  0 
TheNOHDirector
Avatar de TheNOHDirector
Membre du Club https://www.developpez.com
Le 07/10/2009 à 14:32
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.
0  0 
wiztricks
Avatar de wiztricks
Expert éminent sénior https://www.developpez.com
Le 07/10/2009 à 20:18
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
0  0 
Commenter Signaler un problème