Discussion :

[vandeyy]

Bonjour,

Une Interface peut comprendre les signatures/déclarations des méthodes (sans arguments) et des constantes.
Par la suite une Classe hérite l'Interface cette Classe doit redéfinir/implémenter les méthodes déclarées dans l'Interface.
Donc, les méthodes déclarées dans l'Interface sont exploitables uniquement à partir de la classe.

Ex: Quand je regarde dans la java doc pour l'Interface "java.nio.file.Path", je trouve des méthodes exploitables (ex: getFileName, getName, etc.)

Est-ce du polymorphimse / Factoring ?

Merci d'avance,

Yves

[thelvin]

Hello,

Ça veut dire quoi, "exploitable à partir de" ?

Une interface ne sert pas à grand-chose s'il y a pas quelque part une classe qui l'implémente. C'est sûr, et c'est tout ce que ça veut dire. Il n'y a pas que le fait que les méthodes ne sont pas implémentées, il y a aussi le fait qu'on ne peut pas instancier une interface, seulement une classe. Donc si on veut avoir un objet dont le type est une interface, il faut forcément qu'une classe qui l'implémente existe quelque part et soit instanciée quelque part

Ex: Quand je regarde dans la java doc pour l'Interface "java.nio.file.Path", je trouve des méthodes exploitables (ex: getFileName, getName, etc.)

Est-ce du polymorphimse / Factoring ?

C'est... Ben c'est une interface. L'idée des interfaces c'est ça.
Oui, effectivement, le principe des interfaces, c'est de favoriser le polymorphisme, en cela qu'on peut implémenter cette interfaces avec toutes les classes qu'on veut de la manière qu'on veut.

Quant aux objets de type Path, on les obtient en général en appelant Paths.get(), qui renvoie un objet Path. Disons que c'est aussi un genre de factory method.
C'est évident qu'à un moment c'est une classe qui implémente Path qui est instanciée (d'ailleurs on peut savoir laquelle en utilisant System.out.println(Paths.get("machin").getClass()),) mais ça nous concerne pas de savoir laquelle, quand on comment.
Tout ce qui nous concerne, c'est que c'est un objet de type Path. C'est ça le principe des interfaces.

(À noter que depuis Java 1.8 les interfaces peuvent définir des méthodes statiques et des implémentations de méthodes d'instances, dites "default methods". Mais ça ne change pas vraiment ce que sont les interfaces, ça enlève juste quelques contraintes barbantes.)

[vandeyy]

Tout grand merci pour la réponse.

En fait, j'entends "exploitable" car je vois dans la java doc plusieurs méthodes (avec des arguments) dans l'interface Path.





Merci,

Yves

[thelvin]

... Si une méthode est là, elle est là pour s'en servir. Je ne vois vraiment pas quelle est la question -_-°.

[vandeyy]

En effet, je ne peux pas dire le contraire.
Toutefois dans les cours, il est stipulé que les Interfaces ne doivent pas implémenter les méthodes mais juste les déclarer (c'est un contrat).
De ce fait, si je comprends bien les méthodes sont déclarées dans l'Interface mais implémentées dans les Classes qui héritent les Interfaces.

Simple question comment puis-je voir les interfaces du java.nio.file qui sont implémentées pour les classes de java.nio.file ?

Exemple: pour la classe SimpleFileVisitor, je ne vois pas d'Interface implémenté pour cette classe (sauf java.lang.Object)
Idem pour FileSystem, FileStore, FileSystems, StandardWatchEventKinds, ...

J'ai l'impression qu'il y a beaucoup d'Interfaces déclarées dans java.nio.file et que les Classes du java.nio.file n'utilisent pas complétement les Interfaces, qu'en penses-tu ???

J'ai sûrement loupé quelque chose !

Merci,

Yves

[adiGuba]

Salut,

Toutefois dans les cours, il est stipulé que les Interfaces ne doivent pas implémenter les méthodes mais juste les déclarer (c'est un contrat).
De ce fait, si je comprends bien les méthodes sont déclarées dans l'Interface mais implémentées dans les Classes qui héritent les Interfaces.

Oui c'est ca ?

Simple question comment puis-je voir les interfaces du java.nio.file qui sont implémentées pour les classes de java.nio.file ?

Exemple: pour la classe SimpleFileVisitor, je ne vois pas d'Interface implémenté pour cette classe (sauf java.lang.Object)

Ben pourtant c'est indiqué clairement dans la javadoc : http://docs.oracle.com/javase/8/docs...leVisitor.html

Code :

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

1
2
3
4
5
6
7
8
 
All Implemented Interfaces:
    FileVisitor<T>
 
 
public class SimpleFileVisitor<T>
extends Object
implements FileVisitor<T>

Au passage Object n'est pas une interface mais une classe...

Idem pour FileSystem, FileStore, FileSystems, StandardWatchEventKinds, ...

J'ai l'impression qu'il y a beaucoup d'Interfaces déclarées dans java.nio.file et que les Classes du java.nio.file n'utilisent pas complétement les Interfaces, qu'en penses-tu ???

Une classe n'implémente pas obligatoirement une interface.


a++

[thelvin]

Ah ben forcément c'est toujours un peu compliqué, quand on cherche des exemples concrets.

Pourquoi il n'y a pas beaucoup de classes qui implémentent des interfaces ?
Parce que ce n'est pas à ça qu'elles servent, tout simplement.
Ce qui est important de comprendre, c'est que quand tu regardes ce package, dans la doc ou je ne sais où, tu regardes des interfaces et des classes qui sont déjà faites pour que toi, programmeur, tu puisses t'en servir. L'idée c'est que ça te soit utile à toi, pas qu'elles soient utiles les unes aux autres.

Prenons un exemple, tu trouves aucune classe qui implémente Path, bon ok... Ça servirait à quoi ? Pourquoi on te fournirait une classe, que toi tu pourrais utiliser, et qui implémente Path ? Tu as besoin de ça ? Mais non, pas du tout ! Tu as besoin d'une interface Path qui représente un Path, et tu peux en obtenir des instances avec Paths.get(). Pourquoi il y aurait une classe documentée ? Ça sert à rien...
Oui il existe des classes, internes à la bibliothèque Java, qui implémentent Path. Forcément puisqu'il faut bien implémenter l'interface. Mais t'as pas besoin de les voir ces classes, elles te concernent pas. Ce qui te concerne c'est l'interface. Normal donc que tu trouves personne dans la doc qui l'implémente.

À l'inverse, si tu trouves plein de classes qui n'implémentent pas d'interface, ou du moins pas des interfaces de java.nio.file, c'est tout simplement parce que ces classes n'ont pas vocation à implémenter un contrat défini ailleurs. Elles sont ce qu'elles sont et elles sont les seules à l'être, pas besoin d'une interface pour chapeauter une fonctionnalité unique.

Alors pourquoi ces interfaces sont-elles là ?
Je me répète, ce que tu trouves dans la doc, c'est là pour que tu puisses t'en servir, toi. Pas les classes entre elles, toi, le programmeur.
Une interface, qui définit un contrat, ça peut servir à deux choses :
- Ou bien ça te dit ce que tu pourras faire avec les objets qui l'implémentent (genre Path, List, ExecutorService.) Auquel cas il existe différent moyens d'en récupérer des instances, et ces instances qui sont complètement différentes d'un endroit à l'autre, tu peux les traiter pareil, parce qu'elles ont la même interface.

- Ou bien ça te dit ce que toi tu dois implémenter pour respecter ce contrat (genre FileVisitor, Comparator, Predicate.) Auquel cas c'est toi qui dois créer de nouvelles classes qui les implémentent. Et la bibliothèque Java sait comment utiliser ces classes parce qu'elles implémentent l'interface.

- Éventuellement les deux suivant les cas (Comparator par exemple, il peut être fourni ou demandé, ça dépend ce qu'on fait.)


Dans tous les cas, l'interface elle est là pour que tu t'en serves. Pas pour que la bibliothèque s'en serve. C'est donc normal que tu trouves assez peu d'implémentation des unes chez les autres.
Rappelons quand même qu'il y a pas que l'implémentation ou l'héritage dans la vie. Tout ce petit monde utilise quand même assez souvent Path, soit comme paramètre de méthode, soit comme retour de méthode.


Un exemple un peu plus concret d'interfaces et implémentations :
Il vaudrait mieux s'intéresser à la classe ArrayList, qui implémente List, qui étend Collection.
Une List c'est une List, on peut faire plein de trucs avec, notamment tout ce qu'on peut faire avec une Collection. Et donc avec une ArrayList on peut faire tout ça.
ArrayList est une implémentation de List, qui repose sur l'emploi d'un tableau. Et pas, par exemple, d'une liste chaînée (ça c'est LinkedList) ou d'une base de données.

Là tout ça peut servir au programmeur : Collection, List, ArrayList, LinkedList, donc on voit tout bien dans la doc.