Discussion :

[opeo]

Bonjour,
je suis débutant et j'ai déjà lu plusieurs livres sur java. J'aimerai savoir l'intérêt d'avoir les interfaces dans un projet. J'ai lu qu'une interface ne pouvait s'intencier, et n'avait que des méthodes qui sont implémentés(développés ?) dans la classe qui l'implémente. Etant donné que la méthode est développée dans la classe pourquoi mettre sa définition dans une interface ? Je ne comprend pas bien . Je suis un vieux programmeur procédural, j'ai vraiment envie de faire de l'objet, et je suis coincé dans la compréhension de certaines expression comme Interface, etc.
Je vous remercie de votre éclairecissement.

[spoklo]

bonjour,
J'ai eu du mal aussi au début pour comprendre les interfaces en java.

Les interfaces servent à créer des comportements génériques: si plusieurs classes doivent obéir à un comportement particulier, on créé une interface décrivant ce comportement, on est la fait implémenter par les classes qui en ont besoin. Ces classes devront ainsi obéir strictement aux méthodes de l'interface (nombre, type et ordre des paramètres, type des exceptions), sans quoi la compilation ne se fera pas.

Voici un lien qui explique aussi :
http://www.ethnoinformatique.fr/mod/...ew.php?id=1099

voir aussi : http://java.sun.com/docs/books/tutor...interface.html

bon courage

[komando]

bonjour,

une interface est une sorte de contrat qui indique ce que la classe qui l'implémente offre comme service. (un peu l'équivalant des .h en c++)

Leur Intérêt ? Eh bien prenons un exemple.
Disons que j'ai une application qui gére des fichier logs :

Dans une version 1 de mon application, les fichier logs ont un format texte et je crée donc une classe LogText qui gère ce fichier et je l'utilise partout dans le code de mon application

Dans une version 2, les dirigeants ont décidé que le nouveau format du fichier log sera en XML et là j'ai un problème: je dois revoir tout le code de mon application là ou j'ai travaillé avec LogText et les remplacer par la nouvelle classe LogXML

Si depuis le début (version 1), j'avais créé une interface IlogFile qui décrit les méthodes que doit retourner un fichier log et fait implémenter cette interface par LogText et de même pour LogXml, j'aurais eu beaucoup moins de problèmes.

A noter que dans le reste du code, il faut que j'utilise le plus souvent possible l'interface et non l'implémentation.

Voilà, j'espère t'avoir aidé (c'est un exemple concret) et ce n'est qu'un seul avantage des interfaces

[CheryBen]

Voila un petit exemple simple sans code d'interface et classe abstraite :

L'interface :
imagine 2 classes Humain et Félin. Ces 2 êtres sont capables de se laver, mais de façon différente, un félin en se léchant, un humain en prenant une douche.

on va donc créer une interface Lavable qui définit une seule méthode laver() sans paramètre ni retour.

Les 2 classes Humain et Félin vont donc implémenter l'interface Lavable, chacune à leur méthode.

La classe abstraite :
Maintenant on voudrait ajouter tous les autres types d'animaux, ils sont tous capables de se laver, comment être sûr de ne pas oublier d'implémenter Lavable?

Tout d'abord on créé une classe Animal. Tous les animaux héritent de cette classe.

Maintenant c'est Animal qui implémente Lavable. On a supprimé Lavable de Humain et Félin.

D'après le principe des interfaces, Animal devrait donc implémenter Lavable, mais on perdrait le comportement laver() propre à chaque animal. On va donc déclarer la classe Animal comme étant abstraite.

En effet la définition d'une interface est que ses méthodes doivent être déclarées au maximum dans la 1ère classe non abstraite qui l'implémente. Donc Animal étant abstraite, elle n'est pas obligée de déclarer la méthode laver(). Par contre toute classe non abstraite héritant de Animal devra déclarer laver().

Mis à part ça, à quoi sert Animal? elle n'a pas beaucoup d'intérêt... Et bien on peut y définir des comportements commun, on pourrait y définir une méthode déplacer(Coordonnees position) dans laquelle on changerait la position de l'animal à un certain point.


C'est un peu long, mais j'espère avoir été assez clair. A mon avis, pour comprendre la méthode objet, il faut oublier le code et penser à des choses très simples, tout ce qui nous entoure pourrait être représenté de façon objet.

[shurikeNzL]

L'interface :
imagine 2 classes Humain et Félin. Ces 2 êtres sont capables de se laver, mais de façon différente, un félin en se léchant, un humain en prenant une douche.

on va donc créer une interface Lavable qui définit une seule méthode laver() sans paramètre ni retour.

Les 2 classes Humain et Félin vont donc implémenter l'interface Lavable, chacune à leur méthode.

Oui d'accord, mais ça n'explique toujours pas ce qu'apporte les interfaces...

[snakyball]

Grâce à cela tu peux obtenir un code beaucoup plus claire et facile à maintenir. Les programmes qui comportes des interfaces sont plus facilement modulable (le client change d'idées, ...). Comme cité plus haut , avec les interfaces tu garanti un contrat avec différentes entités qui implémenterons obligatoirement les définitions de ce contrat.

Les interfaces apportent de la structure à ton application. Attention toutefois à ne pas mettre des interfaces pour le plaisir d'en avoir partout sinon cela ne rime à rien.

Avec des frameworks comme Spring tu es obligé d'utiliser ce style de programmation.

Bonne journée

[CheryBen]

Pour reprendre mon exemple précédent, l'intérêt est qu'on manipule des objet Lavable à partir des autres classes. On peut appeler leur méthode laver() sans savoir quel type d'objet est instancié ou comment ils implémentent cette méthode.
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Dieu {
    public void gererLesNaissancesDuMonde() {
        Lavable etre = creerUnEtreVivant(); // retourne un nouvel etre vivant dont la race (classe) est aléatoire
        etre.laver(); // parce qu'il faut bien se laver après la naissance :)
    }
}

Un autre développeur pourra facilement implémenter d'autres classes d'êtres vivants sans avoir à modifier cette méthode dont le comportement est générique.

[JoeChip]

Mis à part ça, à quoi sert Animal? elle n'a pas beaucoup d'intérêt... Et bien on peut y définir des comportements commun, on pourrait y définir une méthode déplacer(Coordonnees position) dans laquelle on changerait la position de l'animal à un certain point.

Tu peux par exemple y déclarer une méthode non-abstraite qui utilise la methode "laver"

[Vikisme]

Je me trompe peut-être, mais une interface n'est pas là pour remplacer une classe abstraite qui n'implémenterait concrètement aucune méthode...

Pour moi vous oubliez la raison fondamentale de l'existence des interfaces : L'héritage multiple.

L'héritage multiple est une question qui pose problème. Lorsque l'on hérite de 2 classes qui implémente une même méthode, comment savoir quelle méthode appeler ?
La réponse à cette question que Java à trouvé est la notion d'interface. On hérite concrètement d'une seule classe, mais on peut implémenter plusieurs interfaces. Si on a une méthode définit dans une classe et une ou plusieurs interfaces, la méthode appelée sera alors celle de la super classe, puisque dans les interfaces, cette méthode n'est pas implémentée ! (sauf ci celle-ci est redéfinie dans la classe "fille")

[thelvin]

Je me trompe peut-être, mais une interface n'est pas là pour remplacer une classe abstraite qui n'implémenterait concrètement aucune méthode...

Peut-être pas seulement, mais enfin, le typage fort et rigoureux est aussi un des points fondamentaux de Java. Si une définition de type doit laisser carte blanche aux sous-type pour la totalité de son implémentation (et donc être implémentée d'autant de façons qu'on veut,) autant en prendre une qui ne peut que laisser carte blanche.

Pour moi vous oubliez la raison fondamentale de l'existence des interfaces : L'héritage multiple.

Bon, c'est sans doute le plus important.

[Pedro4]

Je sais bien que donner une référence peut être considéré comme une non-réponse.
Mais un livre qui m'a beaucoup aidé à comprendre l'utilisation efficace des interfaces est le livre Head First Design Patterns.
Il me semble que l'investissement en vaut la chandelle car à la fin du livre on a très bien compris comment rendre ses programmes flexibles grâce entre autres aux interfaces et aux classes abstraites.

[professeur shadoko]

Peut-être pas seulement, mais enfin, le typage fort et rigoureux est aussi un des points fondamentaux de Java. Si une définition de type doit laisser carte blanche aux sous-type pour la totalité de son implémentation (et donc être implémentée d'autant de façons qu'on veut,) autant en prendre une qui ne peut que laisser carte blanche.

le plus important dans une interface est la javadoc!
une interface est un contrat sur lequel le programmeur s'engage...
s'il s'engage sur la méthode "voler()" Il a intérêt à respecter ce qu'on lui demande de faire!

Bon, c'est sans doute le plus important.

le rapport entre les interfaces et l'héritage multiple relève de la légende urbaine: il n'y a absolument pas de rapport direct! (quoiqu'en dise des tas de documents sur le ouèbe).

[Heimdal]

Oui d'accord, mais ça n'explique toujours pas ce qu'apporte les interfaces...

Si la facilité de changement ne t'as pas convaincu c'est peut-être que ça manque de concret.

Je vais repartir sur le cas du Logger.
Le bon design pour la mise en place de souplesse passe souvent par une Factory et tous les accès se font par son biais: Loggers.getLogger();

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public final class Loggers {
 
private Loggers () {}
 
public static ILogger getLogger() {
    return new MonImplementationDeLoggerAvecAccesTresRestreintGenrePrivateOuPackagePrivate();
}
}

Le jour ou tu veux changer tu ne modifie qu'à ce seul endroit, pas besoin de modifier le code dans toutes les classes qui s'en servent.

C'est un premier point, mais comme cité plus haut les interfaces servent avant tout à rendre les traitements génériques et à déléguer l'implémentation à l'objet qui est concerné.
Pour m'appuyer sur l'exemple des Lavable. Mettons que je dispose d'une méthode qui me recense tous les Lavable existants. Je décide de développer une fonctionnalité showerTime où tous les Lavable vont se laver.
Avec ce contrat c'est très simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void showerTime() {
for(Lavable lavable: Environnement.allExistingLavables()) {
lavable.laver();
}
}

Sans cette interface c'est un calvaire, je me débrouille pour savoir de quel type il est, j'appelle une ou des méthodes qui rendent ce service pour tel type, des autres pour tel autre. Enfin bref une gros sac if else for imbuvable et peu évolutif.

[Vikisme]

[...]
le rapport entre les interfaces et l'héritage multiple relève de la légende urbaine: il n'y a absolument pas de rapport direct! (quoiqu'en dise des tas de documents sur le ouèbe).

Personnellement, je ne vois pas quel intérêt aurait une interface si elle pouvait être remplacée par une classe totalement abstraite pour une autre raison que faire de l'héritage multiple.

le plus important dans une interface est la javadoc!

Ca n'est pas tout à fait juste... La javadoc est très importante pour tout le code et pas simplement les interfaces... Les classes totalement abstraites ou partiellement abstraites auront également besoin de javadoc, de même que les api public... C'est un point fort de java, pas des interfaces...

Sinon, en cherchant un peu, j'ai trouvé ceci sur le wikipédia du langage Java :

[...] et l’héritage multiple remplacé par l’implémentation des interfaces.

[thelvin]

Sinon, en cherchant un peu, j'ai trouvé ceci sur le wikipédia du langage Java :

[...] et l’héritage multiple remplacé par l’implémentation des interfaces.

Wikipédia n'est pas sacré... Mais effectivement, le mot-clé ici, c'est l'héritage multiple remplacé par. Et non pas l'héritage multiple réalisé par.
Les interfaces ne permettent pas l'héritage multiple.

Par contre, elles sont le seul moyen en Java de réaliser le sous-typage multiple. Nécessaire et suffisant au polymorphisme appliqué à plusieurs types à la fois.

Alors c'est un peu exagéré d'appeler "légende urbaine" un léger abus de langage.

[Vikisme]

Wikipédia n'est pas sacré...

Je sais bien, mais je pense qu'on peut accorder une bonne crédibilité à cet article étant donné le sujet et la manière dont wikipédia fonctionne. Sans doute plus qu'à un livre sur le java écrit par une ou plusieurs personnes.

Les interfaces ne permettent pas l'héritage multiple.
Par contre, elles sont le seul moyen en Java de réaliser le sous-typage multiple. Nécessaire et suffisant au polymorphisme appliqué à plusieurs types à la fois.

Oui, je pense qu'on veut dire la même chose même si je vois ça de manière plus générale.

le rapport entre les interfaces et l'héritage multiple relève de la légende urbaine: il n'y a absolument pas de rapport direct! (quoiqu'en dise des tas de documents sur le ouèbe).

J'ai l'impression que tu utilise plutôt le terme interface dans le sens de l'API (Application programming interface) ce qui pourrait exiplique le rapport avec la javadoc ?
Pour autant, l'API comme la javadoc ne concerne surement pas uniquement les interfaces au sens Java...
Le fonctionnement entre une classe totalement abstraite et une interface est exactement le même à la différence qu'on ne peut hériter que d'une seule classe même totalement abstraite, alors qu'on peut implémenter plusieurs interfaces. Alors oui, le lien est forcément fait entre la notion d'interface (java) et l'héritage multiple, mais je doute qu'il n'y ait aucun rapport comme tu semble vouloir le dire.

[professeur shadoko]

Je sais bien, mais je pense qu'on peut accorder une bonne crédibilité à cet article étant donné le sujet et la manière dont wikipédia fonctionne. Sans doute plus qu'à un livre sur le java écrit par une ou plusieurs personnes.

ben non justement: regardes l'article en Anglais tu verras que ça n'y est pas ... et pour cause. On peut aussi lire JLS les specifications du langage Java si on est interessé par la bible, on peut aussi lire le bouquin original de James Gosling : la notion d'interface (au sens java) n'a rien à voir avec l'héritage multiple.
Il n'y a pas d'héritage multiple en Java donc si on veut récupérer des comportements de deux classes on peut en hériter d'une et faire une délégation sur une autre , si on veut le polymorphisme avec la deuxième il faudra alors que notre code implante un interface commune avec ce deuxième code ... là on a simulé un héritage multiple (il n'y pas héritage implicite il y a un code explicite) . Maintenant quel est le pourcentage de ce genre de code dans votre utilisation des interfaces????
Dans tous les codes que je lis c'est epsilonesque.

je maintiens ce que j'ai dit: c'est un gros abus de langage (dans le même genre de légende urbaine dire qu'une interface est une classe abstraite dans laquelle toutes les méthodes sont abstraites est faux... malgré les apparences, même source: JLS!)

[Robin56]

Maintenant quel est le pourcentage de ce genre de code dans votre utilisation des interfaces????
Dans tous les codes que je lis c'est epsilonesque.

Je suis assez d'accord avec ce point. En Java, les problématiques d'héritage multiple sont souvent pointées du doigt par des développeurs qui ont souvent un background non Java justement. Pour des développeurs Java, je trouve que l'utilisation majoritaire est l'encapsulation et la notion de contrat entre classes.

[dZastreux]

Bonjour,

Merci à tous ceux qui ont pris le temps d'intervenir sur ce sujet ; pour autant, en ce qui me concerne, je reste perplexe.
Je ne suis certainement pas aussi expérimenté que vous alors j'espère que vous me reprendrez là où je vais dire des bêtises

J'ai le sentiment que vous avez passé beaucoup plus de temps à décrire le fonctionnement des Interfaces et des Classes abstraites ( ou à vous disputailler sur leur raison d'être métaphysique à mi-chemin entre l'héritage multiple et la structure conceptuelle des objets dans le monde qui nous entoure -smiley-hippie-here- ) ...Qu'à vraiment répondre à la question sur le fait de leur intérêt pratique.
En effet, ma déception vient de ce que, dans pour ainsi dire TOUS les exemples que vous avez mentionné, j'arrive à imaginer une simple encapsulation par héritage qui parvient exactement aux mêmes résultats ( la factorisation et la structuration y sont possibles aussi systématiquement avec une bonne analyse ), en terme d'utilisation comme en terme d'évolutivité, et pour peu qu'un peu de rigueur soit maintenue au fil du code, je ne vois juste toujours pas grand intérêt aux abstractions et interfaces, puisqu'au lieu de rendre d'avantage de choses possibles, elles sont juste plus "restrictives"...

Ainsi, par exemple, Heimdal, lorsque tu t'appuies sur l'exemple des "lavables", pour "défendre l'utilisation des interfaces", tu dis :

Mettons que je dispose d'une méthode qui me recense tous les Lavable existants

...Or, si tu disposes d'une telle méthode, même sans utiliser la moindre interface ou abstraction, tu n'auras jamais besoin de faire pour laver() le moindre travail de boucles indigestes : Du moment que le code est écrit rigoureusement et que les félins héritent bien d'un laver() non oublié, comme dans animal, tu pourras sans crainte faire un petit casting ( (Animal) myInstance.getClass()).laver() quelle que soit la classe...
Et ça, sans avoir à faire des fragmentations de classes inutiles avec les interfaces qui rendent à mon sens le code plus éparpillé et donc moins lisible.
De la même façon, je ne vois pas bien, Komando, en quoi l'utilisation des interfaces dispensera le développeur de devoir de toute façon réécrire ses méthodes pour que le XML vienne remplacer le TXT dans ses logs...

Ce que je comprends, c'est que si on gomme le mot "contrat", par exemple, moi ça me fait surtout penser au final à un espèce de post-it : "Bien penser à ramener de la fonction laver()"
Ainsi, certes, surtout dans une équipe, si certains développeurs oublient qu'une méthode a déjà été crée pour tel ou tel truc, le compilateur va leur rappeler en bon post-it en lui disant "hep, t'as oublié de prendre le laver()"
...Mais à part ça ?

En terme d'évolutivité du code, admettons que dans l'interface je change laver() de ma version 1 par purifier() de ma version 2 - Qu'est-ce que ça va changer concrètement ?
...Mon code, lui, "restera sale" puisqu'il y aura toujours des "laver()" un peu partout devenus inutiles et je devrais toujours travailler sur mes "purifier()" dans la superclass ou/et ses filles :
Le compilateur me dira où, en effet, mais un simple CTFRL+F pour "laver()" dans mes .java aussi...
Evidemment, si mes voitures ont aussi un "laver()" qui n'a rien à voire, je perdrai un peu plus de temps, je vous l'accorde.
Mais pour éviter ce cas bien précis de temps perdu, combien de temps perdu à structurer TOUT le code via des interfaces et des abstracts ??

Donc, euh ? Je dois oublier quelque-chose ?
Quand est-ce que ça devient vraiment utile en dehors de l'effet post-it lors de la compilation où on aurait oublié quelque-chose ?
Auriez-vous ne serait-ce qu'un seul exemple valide vraiment concret ?
...D'ailleurs, même chose avec les class abstract du coup :
Qu'apportent-elles de plus, à par la nécessité, contrôlée par le compilateur, de la rigueur du code ?

P.S. Merci beaucoup si vous pouvez m'éclairer là-dessus.

[adiGuba]

Salut,



Une interface décrit un ensemble de fonctionnalités qui doivent être respectés. Bref cela permet de décrire un comportement, mais sans rentrer dans l'implémentation.
Et c'est là tout l'intérêt.

Bien sûr lorsqu'on code notre petit bout de code cet abstraction est souvent inutile.
Mais cela prend tout son sens lorsqu'on voit plus grand (cad un code destiné à être utilisé par d'autres personnes).

Prenons par exemple une simple méthode permettant d'envoyer une newsletter à une liste d'email.
Basiquement on pourrait écrire quelque chose comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void newsletter(String title, String String message, ArrayList<String> emails) {
    for (String email : emails) {
        // send email
    }
}

Notre code marche très bien ainsi... mais il a une grosse limitation : il ne fonctionne qu'avec des ArrayList.
Mais en quoi est-il si important que les emails soient stocké dans un ArrayList pour être passé à newsletter() ?

En fait on s'en fiche complètement de la manière dont les emails sont stocké, du moment que l'on puissent les lire.
Pire cela peut déranger d'autres développeurs qui ne pourront pas utiliser directement la méthode pour diverses raisons :

• Ils ont une liste d'email sous forme de Vector<String>, par exemple car ils utilisent un composant Swing qui utilise encore cette antique classe.
• Ils peuvent également utiliser une LinkedList<String> car ils ont besoin ce cette implémentation pour leurs manipulations des données (suppression du premier élément plus performant).
• Ou ils peuvent avoir une implémentation encore plus spécifique (directement mappé sur une base de données par exemple).

Ils devront obligatoirement convertir leurs données en une ArrayList, uniquement pour utiliser ta méthode.

Mais le pire c'est que ce critère est un peu inutile : la méthode newsletter() n'a pas besoin d'une "liste d'email implémenté par un tableau redimensionné dynamiquement", mais simplement d'une "liste d'email".
Donc tu peux très bien remplacer ArrayList par List :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void newsletter(String title, String String message, List<String> emails) {
    for (String email : emails) {
        // send email
    }
}

Désormais tu ne sais pas comment sera implémenté la liste d'email... mais tu t'en fous un peu.
Et tous les développeurs précédent te remercieront car ils pourront utilisé ta méthode directement.

Tu ne connais pas le fonctionnement exact de la liste (et tu ne l'imposes pas), mais l'interface te garantie l'existence des méthodes dont tu as besoin.


Et on peut même aller plus loin : on a remplacé ArrayList par List pour faire abstraction de l'implementation, mais on peut également réduire les contraintes.
Une List c'est une collections de données "ordonnées"... mais cet ordre ne nous sert à rien dans la méthode newsletter().
On pourrait donc se contenter d'utiliser l'interface Collection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void newsletter(String title, String String message, Collection<String> emails) {
    for (String email : emails) {
        // send email
    }
}

Encore une fois sans toucher à notre code mais simplement à la déclaration des paramètres, on élargit le scope de la méthode.
Elle pourra désormais être utilisé avec de nouveaux types n'ayant pas forcément de notion d'ordre (comme les Set qui permettent d'assurer l'unicité des données).


Mieux : Collection définit un ensemble d'élément qui peuvent être modifié... mais encore une fois on on n'a pas besoin de cela non plus.
On peut se contenter d'utiliser l'interface Iterable qui défini un ensemble dont on peut parcourir les éléments. Pile poil ce que l'on fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static void newsletter(String title, String String message, Iterable<String> emails) {
    for (String email : emails) {
        // send email
    }
}

Bref, en faisant abstraction de l'implémentation, et en choisissant méticuleusement l'interface selon notre besoin, on a considérablement élargit les possibilités d'utilisation de notre méthode.
Chaque interface défini un niveau d'abstraction plus ou moins grand...




Dans la vrai vie aussi on peut retrouver plusieurs niveaux d'abstractions :

• Si tu veux acheter une voiture, tu veux connaitre le type exact (= modèle exacte).
• Si tu veux louer une voiture, tu peux te contenter d'une gamme (citadine, break, monospace, voiture de luxe) sans forcément connaitre le modèle précis.
• Si tu dois faire le plein, tu as juste besoin de savoir si c'est un moteur essence, diesel ou GPL.
  Tu te fiches de savoir qu'il a un 4 ou 5 places, un GPS, un toit ouvrant ou n'importe quelle autre option...
• ...

a++