Je voulais savoir d'après vous c'est quoi exactement l'interet des interfaces en java, car perso, je trouve qu'elles sont inutiles, pourquoi ne pas implémenter directement dans les classes concretes sans passer par des interfaces???
Je voulais savoir d'après vous c'est quoi exactement l'interet des interfaces en java, car perso, je trouve qu'elles sont inutiles, pourquoi ne pas implémenter directement dans les classes concretes sans passer par des interfaces???
Et l'intérêt de la fonction recherche ? Inutile aussi ?
c'est quoi le rapport ? pour toi c quoi l'interet ?Envoyé par nicØB
Une interface permet beaucoup!!
Une interface, c'est un contrat: une classe qui implémente "Comparable" permet de comparer plusieurs instances de cette classes entre elles afin de définir laquelle est supérieure ou inférieure.
Implémenter une interface, ça revient à déclarer "cette classe est capable de faire ceci".
C'est en utilisant les interfaces que l'on peut "simuler" un héritage multiple (la terminologie que j'emploie n'est pas tout à fait exacte): une classe peut implémenter Comparable, Cloneable, Iterable, et plein d'autres interfaces. Cela permet de "greffer" des fonctionnalités sur des classes.
Cela permet aussi d'utiliser des classes sans se préoccuper de leur type réel et de leur implémentation, afin de pouvoir tout modifier plus facilement par la suite.
L'exemple typique des listes:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 ArrayList a = new ArrayList(); // Mauvais, car "ArrayList" est référencé directement, alors qu'il ne s'agit que d'une implémentation de Collection Collection c = new ArrayList(); // Bon, car on peut facilement modifier "new ArrayList()" par "new HashTable()" ou "new TreeSet()", sans que cela modifie le reste du programme
Les interfaces sont sans doute l'une des meilleure trouvail de Java!
![]()
Ce n'est pas la première fois que quelqu'un pose cette question.Envoyé par gloglo
![]()
Un autre intérêt pour ma part c'est lorsque l'on utilise Spring (ou autre lib permettant de faire de l'injection de dépendances).
Celon le contexte, on charge l'implémentation que l'on veut.
Je crois que ta question risque de provoquer des arrets cardiaques à pas mal de personne ici. Une interface permet de décrire un comprotement particulier. C'est un moyen de typer les objets par leur competences (les méthodes qu'ils savent executer) plutot que par leur classe.
De plus, utiliser des interfaces te permet d'introduire beaucoup de souplesses dans le developpement de ton application. Imagine que pour un algorithme tu necessite de calculer la distance entre deux points (algorithme A* par exemple). Il existe différent types de distances (euclidienne, de Manhattan, diagonale ...). Si tu veux que ton application soit modulaire, tu as tout interet a manipuler une interface qui contient une methode calculerDistance plutot qu'une implementation directement. Je te conseille un ouvrage interessant qui aborde notamment ce sujet et plus generalement la "bonne" facon de concevoir une appli orientée objet : "design patten : la tete la premiere" chez oreilly
Il n'y a pas possibilité d'héritage multiple en java, donc on passe par les interfaces. Par exemple, il suffit de regarder dans l'api standard. Si tu prends l'interface List, il y a plusieurs classes qui implémente cette interface, de leur propre manière. Et si tu dois manipuler des lists de toute sorte, tu n'aura qu'à manipuler l'interface.
Les interfaces sont utilisées dans les pattern de type Factory ou pour l'injection de dépendance.
Les interfaces sont des contrats que les classes qui les implémentent doivent respecter, même si le développeur peut les implémenter comme il veut. Il manque peut-être un mécanisme de contrôle type programmation par contrats.
Une interface decrit le contrat que doit respecter une implementation. Exemple concret :
Si tu prends le moteur Essence ou Diesel, la classe devra respecter (implementer) au MINIMUM ces 3 méthodes. Bien-sûr le corps des méthodes est completement libre (le demarrage d'un moteur essence ne se faisant pas de la même manière qu'un moteur essence).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 public interface Moteur { void demarrer(); void arreter(); void pause(); }
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 public abstract class Moteur { public abstract void demarrer(); public abstract void arreter(); public abstract void pause(); }
Dans certains cas je préfère un abstract. J'ai parfois du mal à choisir entre interface et classe abstraite. L'avantage d'une interface c'est qu'une classe peut hériter de plusieurs interface alors qu'une classe ne peut étendre qu'une seule classe abstraite ...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 public class MoteurEssence extends Moteur { }
Tout dépend du contexte ...
Envoyé par sleepy2002
dans ce cas je ne vois pas l'utilité de la classe abstraite étant donné que tu ne définie aucune méthode.Envoyé par pgervaise
Une interface serait donc mieux adapté.
L'avantage d'une interface c'est quand tu veux un type générique sans avoir à te préoccuper de la manière dont seront réaliser les choses.
Suppose qu'on te demande de faire une application chargé de gérer l'envoie de message à des personnes d'un listing. Sauf que les moyens d'expédition du message sont différents. Certaine personnes le voudraont par mail, d'autres par courrier, d'autre par mail (et j'en passe).
Sans interface, tu te retrouve à faire :
avec toute les déclarations et définitions qui vont avec (soit trois objets minimum).
Code : Sélectionner tout - Visualiser dans une fenêtre à part Sms.envoie(message); ou Mail.envoie(message); ou Courrier.envoie(message)
Avec l'interface tu pourrais faire :
avec seulement Envoyeur qui définit Sms, Mail ou Courier en fonction du clients.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Envoyeur.envoie(message)
Demain, on invente un nouveau moyen de communication (holovision par exemple). Dans le premier cas tu dois tout refaire pour ce nouveau moyen, dans le second tu implément Envoyeur tu ajoute une condition et c'est fini.
Je me suis un peu laisser aller désolé![]()
Bonjour à toutes et à tous,
Sans vouloir polémiquer, mais pour avoir les idées plus claires sur la différence entre classe abstraite et interface, quelqu'un pourrait-il écrire un petit programme basé sur l'exemple précédent (des destinataires, des moyens d'expédition) en utilisant d'un côté des classes abstraites et de l'autre des interfaces.
Pour moi :
- avec des interfaces : il faut créer autant d'interfaces qu'il y a de moyens d'expédition, puis créer une classe implémentant toutes ces interfaces. Si on ajoute un moyen d'expédition, il faut créer une nouvelle interface, l'implémenter dans la classe utilisatrice et faire un nouveau "switch" dans cette classe.
- avec des classes abstraites, il faut créer autant de classes à partir de la classe abstraite qu'il y a de moyens d'expédition, puis une classe qui exploite chacune des classes précédemment créées. Si on ajoute un moyen d'expédition, il faut créer une nouvelle classe issue de la classe abstraite et ajouter un "switch" dans la classe utilisatrice.
Voilà ce que j'ai compris, mais je suis peut-être complètement à côté de la plaque. C'est pourquoi un petit programme valant mieux que de longs discours ...
Au niveau applicatif, le listing comprend bien des couples "destinataire/moyen d'expédition" qui vont exploiter les ressources définies ci-dessus.
Merci de votre aide.
Pierre.
Hello,
il n'y a pas vraiment de solution purement "interface" ou purement "classe abstraite"
La meilleure logique serait de partir d'une interface, de l'implémenter dans une classe abstraite, puis de définir des classes concrètes à partir de la classe abstraite.
De toute façon, au final, le code doit se trouver dans des classes... L'utilisation d'interfaces ne fait que modifier le type de référence.
Une implémentation de l'exemple ci-dessus pourrait être comme cela:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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 // Déclare l'interface d'un envoyeur interface Sender { void setRecipient(String s); void send(String msg); } // Ici, je défini l'implémentation standard de tous les "Sender", par ex. "setRecipient(String)" qui permet d'affecter un destinataire // Les classes abstraites contiennent généralement des implémentations standards pouvant être modifiés par les sous-classes abstract class AbstractSender implements Sender { protected String recipient; public void setRecipient(String s) {recipient = s;} public void toString(){ return "Sender de classe "+getClass().getSimpleName(); } } // Maintenant, je passe aux implémentations concrète class SMSSender extends AbstractSender { public void send(String msg){ System.out.println("Envoi de "+msg+" par sms à "+recipient); } } class MailSender extends AbstractSender { public void send(String msg){ System.out.println("Envoi de "+msg+" par mail à "+recipient); } } class PigeonVoyageurSender extends AbstractSender { public void send(String msg){ System.out.println("Envoi de "+msg+" par pigeon voyageur à "+recipient+"!"); } } // Une "main" pour tester public static void main(String[] arg){ Sender s = new MailSender(); System.out.println(s); s.setRecipient("toto@toto.com"); s.send("Ceci est le message 1"); s = new PigeonVoyageurSender(); System.out.println(s); s.setRecipient("E32.3N45.5"); s.send("Ceci est le message 2"); }
Partager