interface utile ou inutile

Bonjour,
j'ai un trouvé un code comme celui-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

public interface IFait { String Nom(); Object Valeur(); int Niveau(); void setNiveau(int l); }   class FaitBooleen implements IFait {   protected String nom; @Override public String Nom() { return nom; }   protected boolean valeur; @Override public Object Valeur() { return valeur; }   protected int niveau; @Override public int Niveau() { return niveau; } @Override public void setNiveau(int l) { niveau = l; } } class FaitEntier implements IFait { protected String nom; @Override public String Nom() { return nom; }   protected int valeur; @Override public Object Valeur() { return valeur; }     protected int niveau; @Override public int Niveau() { return niveau; } @Override public void setNiveau(int n) { niveau = n; }

---

A quoi sert l'implémentation de l'interface

Code:

---

public interface IFait

---

dans les deux classes

Code:

---

1 2 3

class FaitEntier implements IFait class FaitBooleen implements IFait

---

puique les classes en question définissent les méthodes implémentées, ce qui se passerait exactement de la même manière sans interface et en faisant apparaitre les méthodes directement dans les classes.
Merci d'avance même si je pose une question peut-être très naîve

C'est une implémentation bancale dans cet exemple. En plus de ne respecter aucune convention java.

Toutes les implémentations auront le même code. Le seul intérêt des différentes implémentation serait de marquer le type de retour. Ce à quoi échoue l'implémentation, puisque le type de retour de valeur ne change pas. Cette interface et ses implémentation pourrait allègrement être remplacée par cette unique classe.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public class Fait<T extends Object> { public Fait(String nom, T valeur, int niveau){ this.nom=nom; this.valeur = valeur; this.niveau=niveau; } public String getNom(){ return nom; } public T getValeur(){ return valeur; } public int getNiveau(){ return niveau; } public void setNiveau(int niveau){ this.niveau=niveau; } }

---

merci,
cependant d'après la raison d'être d'une interface tel que celle-ci :

Code:

---

1 2 3 4 5 6 7 8

public interface InterFace { String methode1(); Object methode2(); int methode3); void methode4(int argument); }

---

c'est d'être implémentée dans une classe tel que celle-ci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Classe implements InterFace {   protected String nom; public String Methode1() { return nom; }   protected int valeur; public Object Methode2() { return valeur; }   protected int niveau; public int Methode3() { return niveau; } public void Methode4(int argument) { niveau = argument; } }

---

Je ne vois pas d'autres schémas possibles, pourrais tu me dire où je fais erreur car c'est évident que le code que j'ai écrit en exemple ne sert à rien, et il s'inspire d'un livre sérieux, d'une maison d'édition sérieuse, je ne sais si j'ai le droit de les citer ils ne traitent que de littérature informatique pourtant !

merci !

Salut,

La raison d'être d'une Interface, c'est de pouvoir définir des méthodes, sans fournir d'implémentation. On parle de défnir un contrat. Une façon dont on dit "pour se servir de mon système, faites des classes qui implémentent mon interface". Bien sûr dans un programme qui manipule directement une classe truc, l'interface est superflue : on a l'implémentation de la classe, ça suffit. Mais si tu fais un système qui gère un truc (une API par exemple), mais que tu ne veux pas imposer d'implémentation (ou ne pas de restreindre à un nombre fini de cas), et bien tu fais une interface, et ceux qui voudront se servir de ton système, ils implémenteront simplement l'Interface dans leur(s) classe(s).

Par exemple, si tu fais un programme de télécommande virtuelle pour déplacer en 2D un mobile tu peux faire une interface par exemple du type :

Code:

---

1 2 3 4 5 6 7 8

public interface Mobile {   void avancer(); void reculer(); void tournerADroite(); void tournerAGauche();   }

---

Ton sysème manipulera uniquement des variables de type Mobile. Et ceux qui voudront utilsier ton système implémenteront l'interface sur leur classe. Ce qu'il y a derrière, tu n'as pas à t'en soucier, que le mobile soit un sprite sur un écran, un robot mécanisé, ou une simulation virtuelle sans affichage, ou n'importe quoi d'autres.

Merci pour ta réponse, c'est plus clair pour moi,
mais j'ai juste besoin de tes lumières un petit peu plus :
avec ton interface :

Code:

---

1 2 3 4 5 6 7 8

public interface Mobile { void avancer(); void reculer(); void tournerADroite(); void tournerAGauche();   }

---

ne faudra-t'il pas utiliser une classe comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class ImpMobile implement Mobile { void avancer() {definition de la méthode avancer}   void reculer() {définition de la méthode reculer}   void tournerADroite(){ définition de la méthode tournerADroite}   void tournerAGauche(){ définition de la méthode tournerAGauche} }

---

Je n'arrive pas à sortir de ce schéma, donc bien sur je me pose toujours la question : a quoi sert le passage intermédiaire par l'interface au lieu de se contenter de la classe.
Pourrais-tu me montrer un "schéma" où l'interface ne serait pas simplement dupliquée en plus complet dans la classe.
Merci

Citation:

---

Envoyé par philipix

a quoi sert le passage intermédiaire par l'interface au lieu de se contenter de la classe.

---

A pouvoir coder un système de gestion sans avoir à fournir/imposer d'implémentation concrête, dont le code ne concerne pas le système de gestion.

Prenons un exemple plus concrêt : l'accès au données d'une base de données via JDBC. L'interface du JDK java.sql.ResultSet est définie comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public interface ResultSet extends Wrapper, AutoCloseable { /** des constantes **/   boolean next() throws SQLException;   void close() throws SQLException;   boolean wasNull() throws SQLException;   String getString(int arg0) throws SQLException;   /* etc */

---

Java propose donc une solution générique d'accès à un fournisseur de données, appelée JDBC. Qui développe une base de données, ou je ne sais quoi, et veux être compatible JDBC va developper ses propres classes, dont une est l'implémentation concrête de ResultSet pour son système. Comme ça Sun à l'époque n'était pas obligé de développer les dizaines d'implémentations de SGBD existant et de fournir des patchs sans arrêt pour des SGBD pas encore inventés à ce moment-là, non développés par Sun de surcroît.

De même, ResultSet étend AutoCloseable, une interface qui permet au JDK de mettre en place un système automatique de libération de ressources. Un autre intérêt de l'interface.

Encore plus édifiant, l'interface java.util.function.Function :

Code:

---

1 2 3

@FunctionalInterface public interface Function<T, R> { }

---

Une interface qui permet de proposer un système qui permet de gérer une transformationd'une valeur de type T vers une valeur de type R. Sans savoir à coder d'avance l'infinité de transformations possible d'un type T vers un type R. Ce qui serait évidemment impossible, tu ne crois pas ?

Ainsi, ça permet à l'API Java de proposer l'interface Stream qui a une méthode :

Code:

---

<R> Stream<R> map(Function<? super T, ? extends R> arg);

---

qui permet de transformer facilement un Stream<T> en Stream<R> (d'autant plus facilement qu'on peut utilier une expression lambda pour l'implémentation concrête).

Et l'API peut le faire sans avoir à fournir l'infinité d'implémentations concrêtes possibles. En d'autres termes, on peut fournir un système en s'en foutant complètement de l'implémentation concrête, et bien heureusement, parce qu'on ne peut pas la prévoir d'avance dans une infinité de cas.

Merci,
Je vais prendre acte de ta réponse et m'en inspirer au plus juste.
a+