Discussion :

[kullervo]

Bonjour,

j'ai un petit soucis, je sais que le sujet des classes abstraites et des interfaces revient régulièrement, j'ai lu beaucoup de choses, mais j'ai pas vraiment trouvé de réponses ou alors je n'ai pas eu le déclic qui m'a fait comprendre.

En fait je pense avoir compris l'utilité d'une classe abstraite, et je trouve que ça à l'air plutôt utile (je n'ai pas encore eu l'occasion de l'utiliser) avec la possibilité de définir des méthodes communes et d'autres à redéfinir suivant les cas et j'ai même l'impression que ça peut être utiliser dans la majorité des cas (sauf s'il y a déjà une un héritage).

Par contre, l'interface, ok, c'est utilisable dans le cas ou il y à déjà un héritage. Mais toutes les méthodes déclarées doivent être redéfinies, arrêtez moi si je me trompe. Donc en fait mes 2 questions, sont :

S' il faut tout redéfinir, puisqu'il n'y a que des méthodes abstraites dans l'interface, autant ne pas faire d'interface et redéfinir directement dans les classes , ça revient au même (à part le fait que l'interface lorsqu'elle est implémentée oblige à redéfinir la méthode donc il n'est pas possible de "l'oublier" mais ça fait léger comme avantage je trouve) ?

Ensuite, je n'arrive pas à voir dans quel cas l'utiliser, je veux dire, quel cheminement dans l'esprit amène à dire : ah là, c'est obligé je dois faire une interface (une fois de plus, a part le fait qu'il n'y ai pas d’héritages multiples) puisqu'il faut tout redéfinir (contrairement à une classe abstraite qui peut avoir des méthodes non abstraites communes à toutes les classes filles) ? En fait j'ai surtout l'impression que l'interface ne sert pas à grand chose, même dans les nombreux exemples lus, je me dis : sans interface c'est pareil. WTF ?

Je sais que les questions sur les interfaces reviennent souvent, et je m'excuse par avance de vous saouler avec ça, et pourtant j'ai pas mal fouiller (ici, stackoverflow, etc...) mais je pense surtout que je n'ai pas eu le "déclic" qui m'a permis de comprendre.

Merci à vous.

[OButterlin]

C'est assez fréquent de ne pas comprendre immédiatement l'intérêt des interfaces

Je vais essayer de t'expliquer à ma façon... Il suffit de voir le problème sous un autre angle.
L'interface devrait être comprise comme un contrat que remplit la classe qui l'implémente, avec comme gros avantage de pouvoir étendre plusieurs interfaces.

On va imaginer une "tour de contrôle globale" qui serait en charge de la bonne marche de tous les véhicules "mobiles".
Pour faire simple, on définira l'interface "Deplaçable2D" avec "avancer", "reculer", "tournerAGauche", "tournerADroite" et une autre interface "Deplaçable3D" qui étendra "Deplaçable2D" mais qui ajoutera "monter", "descendre".
Il va de soi qu'un avion étendra le contrat "Deplaçable3D" alors qu'une voiture n'étendra que "Deplaçable2D".

Maintenant, on se place uniquement dans la perspective du "roulage", seule l'interface "Deplaçable2D" n'est utile et du coup, on pourra représenter un avion ou une voiture comme "Deplaçable2D" pour transmettre les demandes.

Pour ce qui est de l'implémentation, il est certain que la voiture utilise une chaîne d'ordres très différente qu'un avion, ne serait-ce que pour avancer, mais ça, du point de vue du contrôleur, on s'en fiche, on ne les voit que sous la forme de "Deplaçable2D", chose qu'ils sont tous les 2.
Là, une classe abstraite ne serait d'aucune utilité, ou alors il faudrait qu'elle teste tout le temps : si je suis un avion, je tourne en faisant ceci, si je suis une voiture, je tourne en faisant celà...

Bref, en résumé, voit l'interface comme un contrat, pas comme une implémentation.

[professeur shadoko]

autres exemples:

Classe abstraite: outil de mutualisation
tu as des clients qui sont des "personnes physiques" et d'autres des "personnes morales", l'un ne peut hériter de l'autre mais on peut créer un type abstrait "Acheteur" pour regrouper un certain nombre de points communs.

Interface: "contrat" .. des codes qui n'ont aucun rapport entre eux s'engagent sur une capacité de réalisation d'un "contrat"
Interface "Messager" (capable d'envoyer un message)
implantations: Mail, CourrierPapier, SMS, Fax, etc...

Et après un "Acheteur" pourra avoir un agent "Messager" pour lui envoyer un message! (en plus d'une Adresse, d'un historique des opérations, etc...)

[kullervo]

Tout d'abord merci à toi d'avoir pris le temps de répondre.

Si je peux me permettre d'abuser encore de ton temps...

C'est assez fréquent de ne pas comprendre immédiatement l'intérêt des interfaces

Ça me rassure.

On va imaginer une "tour de contrôle globale" qui serait en charge de la bonne marche de tous les véhicules "mobiles".
Pour faire simple, on définira l'interface "Deplaçable2D" avec "avancer", "reculer", "tournerAGauche", "tournerADroite" et une autre interface "Deplaçable3D" qui étendra "Deplaçable2D" mais qui ajoutera "monter", "descendre".

Je m'étais pas rendu compte qu'une interface pouvait étendre une autre, mais bon c'est un détail dans mon cas de difficulté de compréhension.

Pour ce qui est de l'implémentation, il est certain que la voiture utilise une chaîne d'ordres très différente qu'un avion, ne serait-ce que pour avancer, mais ça, du point de vue du contrôleur, on s'en fiche, on ne les voit que sous la forme de "Deplaçable2D", chose qu'ils sont tous les 2.
Là, une classe abstraite ne serait d'aucune utilité, ou alors il faudrait qu'elle teste tout le temps : si je suis un avion, je tourne en faisant ceci, si je suis une voiture, je tourne en faisant celà...

En fait il est là mon problème, je pense avoir compris qu'une interface il n'y a que des en-têtes de méthodes, qui sont ensuite définies dans les classes qui implémentent l'interface. Je pense que jusque là j'ai bon. MAIS, pourquoi faire une interface, alors que l'on pourrait directement définir les méthodes dans les classes sans faire d'interface pour gagné du temps ? J'ai l'impression que l'interface en fait, c'est juste une espèce de plan, de toDo List, ou d'aide mémoire, du genre : tu implémentes l'interface, du coup l'interface t'indique : "Y a une méthode, peu importe comment tu la défini, je m'en moque, je veux juste qu'elle soit présente dans la classe." en gros un moyen de ne pas oublier d'inclure une ou des méthodes dans une classe.

J'espère ne pas avoir dit trop d'énormités, et je te remercie encore.

[kullervo]

Merci à toi pour ta réponse, si je peux t’embêter encore un peu...

autres exemples:

Classe abstraite: outil de mutualisation
tu as des clients qui sont des "personnes physiques" et d'autres des "personnes morales", l'un ne peut hériter de l'autre mais on peut créer un type abstrait "Acheteur" pour regrouper un certain nombre de points communs.

Jusque là ok.

Interface: "contrat" .. des codes qui n'ont aucun rapport entre eux s'engagent sur une capacité de réalisation d'un "contrat"
Interface "Messager" (capable d'envoyer un message)
implantations: Mail, CourrierPapier, SMS, Fax, etc...

Lorsque tu écris, implantations, tu parles de classes Mail, SMS, Fax, etc ?
Comme je le dis à OButterlin, en fait, puisque les méthodes dans l'interface Messager ne contiennent que l'en-tête, ça revient au même de ne pas faire d'interface et de mettre la méthode dans chaque classe ? Puisque de toute façon il faudra définir la méthode pour chaque classes. (puisqu'elle ne l'est pas dans l'interface)

Et après un "Acheteur" pourra avoir un agent "Messager" pour lui envoyer un message! (en plus d'une Adresse, d'un historique des opérations, etc...)

Par contre j'ai pas compris ce que tu entends par "agent".

Voila, je te remercie encore de m'aider à mettre de l'ordre dans mon esprit.

[thelvin]

Hello,

Comme je le dis à OButterlin, en fait, puisque les méthodes dans l'interface Messager ne contiennent que l'en-tête, ça revient au même de ne pas faire d'interface et de mettre la méthode dans chaque classe ? Puisque de toute façon il faudra définir la méthode pour chaque classes. (puisqu'elle ne l'est pas dans l'interface)

Mais dans ce cas, tu seras obligé d'appeler l'une des méthodes de ces classes-là, Email.envoyerMessage() ou Sms.envoyerMessage() ou qu'importe. Puisqu'il n'y aurait même pas de classe générale "Messager".

Ça veut dire que tu te prives de l'opportunité de décider que ta classe en cours, ce n'est pas son problème comment on fait pour envoyer un message. Pour ça, elle a un objet de type Messager dont, lui, c'est son problème et qui, lui, sait ce qu'il faut faire.

Tu t'imposes de faire des choix de programmation à l'intérieur d'une classe dont le rôle n'est pas de faire ces choix.

À quoi bon ? Laisse chaque classe faire son travail à elle et pas celui des autres. Et définis une interface Messager dont ces classes prendront une instance, sans jamais se soucier de quelle est la classes concrète de cette instance. Tout ce qui importe, c'est qu'on peut appeler envoyerMessage() dessus.

[foetus]

J'ai l'impression que l'interface en fait, c'est juste une espèce de plan, de toDo List, ou d'aide mémoire, du genre : tu implémentes l'interface, du coup l'interface t'indique : "Y a une méthode, peu importe comment tu la défini, je m'en moque, je veux juste qu'elle soit présente dans la classe." en gros un moyen de ne pas oublier d'inclure une ou des méthodes dans une classe.

Tu as raison mais cela va dans les 2 sens (Interface <-> Classe Utilisatrice) :

• Une interface permet effectivement de contraindre les méthodes de la classe utilisatrice. C'est un contrat, la classe utilisatrice doit avoir telles et telles méthodes.
• Une classe utilisatrice pourra être utilisée via ces interfaces. On va faire des listes d'interfaces. Pour reprendre l'exemple de OButterlin, on peut faire des tableaux d'objets Deplaçable2D ou d'objets Deplaçable3D. Comme on connait les méthodes de l'interface, c'est juste ce qu'il nous faut.

[yildiz-online]

Comme dit précédemment, une interface est un contrat, dit autrement, c'est ce qu'on va montrer à l'utilisateur, un exemple concret:

Ceci est un module physique pour un moteur de jeu (j'ai retiré les commentaires et la licence(mit) pour plus de lisibilité, le code original est ici : https://github.com/yildiz-online/module-physics ).
Ce module doit interagir avec le moteur de jeu, qui va lui donner des instructions(faire une mise à jour du monde, calculer les collisions, stopper ou démarrer le moteur, et l'utilisateur de la classe, lui n'a pas à utiliser ces instructions, il n'en a pas le droit:
(La classe est abstraite mais ne t'en préoccupe pas, ce n'est pas important ici)

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
49
50
51
52
53
54
 
package be.yildizgames.module.physics;
 
import be.yildizgames.module.physics.dummy.DummyPhysicEngineProvider;
 
import java.util.ArrayList;
import java.util.List;
import java.util.ServiceLoader;
 
public abstract class BasePhysicEngine implements PhysicEngine {
 
    private final List<PhysicWorld> worlds = new ArrayList<>();
 
    private boolean stop;
 
    protected BasePhysicEngine() {
        super();
    }
 
    public static BasePhysicEngine getEngine() {
        ServiceLoader<PhysicEngineProvider> provider = ServiceLoader.load(PhysicEngineProvider.class);
        return provider.findFirst().orElseGet(DummyPhysicEngineProvider::new).getPhysicEngine();
    }
 
    public final void update() {
        this.worlds.forEach(PhysicWorld::update);
    }
 
    public final void close() {
        this.stop = true;
        this.worlds.forEach(PhysicWorld::delete);
        this.worlds.clear();
    }
 
    public final void start() {
        new Thread(this::runEngine).start();
    }
 
    @Override
    public final PhysicWorld createWorld() {
        PhysicWorld w = this.createPhysicWorldImpl();
        this.worlds.add(w);
        return w;
    }
 
    protected abstract PhysicWorld createPhysicWorldImpl();
 
    private void runEngine() {
        while(!this.stop) {
            this.update();
        }
    }
 
}

Si je donne une instance de BasePhysicEngine à l'utilisateur, il aura tout pouvoir sur cette classe, ce qui n'est pas souhaitable, alors que si je ne lui donne que l'interface, il n'aura pas accès aux fonctions réservées au moteur de jeu:

Code :

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

1
2
3
4
5
6
7
 
package be.yildizgames.module.physics;
 
public interface PhysicEngine {
 
    PhysicWorld createWorld();
}

Tout ce qu'il peut faire est de créer un monde, impossible pour lui d'utiliser quoi que ce soit d'autres (sauf downcast bien entendu).
C'est bien pour lui, il ne doit pas se compliquer la vie avec un tas de fonctions qui ne l'intéresse pas, et c'est bien pour le concepteur de la classe, qui ne recevra pas de ticket de bug parce que quelqu'un a fait une mauvaise manipulation avec les fonctions réservées.

[OButterlin]

Pour poursuivre mon exemple, la problématique de l'implémentation dans la classe sans définition d'une interface conduirait à devoir tester tous les types dans ton processus de déplacement des "mobiles".
On te donne une liste d'avion et de voiture et tu appliques la méthode "tournerAGauche" sur chaque objet, donc ça t'oblige à tester le type avant d'appliquer la méthode.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
for (Object mobile : (List<Object>)mesObjetsDeplaçable2D)
{
   if (mobile instanceof Avion)
   {
      ((Avion)mobile).tournerAGauche();
   }
   else if (mobile instanceof Voiture)
   {
      ((Voiture)mobile).tournerAGauche();
   }
}

On voit tout de suite qu'il faut connaître à l'avance tous les types qu'on va utiliser alors qu'avec l'interface (à comprendre comme une capacité à faire quelque chose) ça se résumerait à

Code :

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

1
2
3
4
for (Deplaçable2D mobile : (List<Deplaçable2D>)mesObjetsDeplaçable2D)
{
   mobile.tournerAGauche();
}

avec comme énorme avantage qu'on pourra ajouter par la suite un objet "Bateau", "Velo", etc... sans avoir à reprendre ce code (alors que dans l'autre version, il faudra rajouter nos else if (... instanceof ...)).

Encore une fois, l'interface sert à voir un objet non pas sous la forme de son implémentation mais sous la forme d'une capacité à faire quelque chose.

[professeur shadoko]

Et j'en rajoute une couche

Code écrit par Bob:

Code :

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

1
2
3
4
5
6
7
8
Acheteur laBoite = new PersonneMorale(descriptionSociété) ;
laBoite.setMessager(new Fax(10666666)) ;
 
Acheteur clientDuJour= new PersonnePhysique(descriptionPersonne) ;
clientDuJour.setMessager(new EMail("grandschtroumpf@smurf.com") ;
 
listeClients.add(laBoite) ;
listeClients.add(clientDuJour) ;

Code écrit par Alice (qui ne connait pas le détail des clients).

Code :

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

1
2
3
for(Acheteur acheteur : listeClients) {
  acheteur.getMessager().sendMessage("Meilleurs voeux pour 2048!") ;
}

Alice n'a pas à savoir comment le message part!

Plus tard Basil rajoutera un code pour créer un messager qui permet de passer par une application à la mode (suivez la direction de mon regard).

Donc découplage!

Bob travaille à Paris pour l'agence française de notre compagnie.
Alice travaille à Bruxelles au siège de la compagnie
Basil est développeur de maintenance à Talinn

[kullervo]

Mais dans ce cas, tu seras obligé d'appeler l'une des méthodes de ces classes-là, Email.envoyerMessage() ou Sms.envoyerMessage() ou qu'importe. Puisqu'il n'y aurait même pas de classe générale "Messager".

Ça veut dire que tu te prives de l'opportunité de décider que ta classe en cours, ce n'est pas son problème comment on fait pour envoyer un message. Pour ça, elle a un objet de type Messager dont, lui, c'est son problème et qui, lui, sait ce qu'il faut faire.

Tu t'imposes de faire des choix de programmation à l'intérieur d'une classe dont le rôle n'est pas de faire ces choix.

À quoi bon ? Laisse chaque classe faire son travail à elle et pas celui des autres. Et définis une interface Messager dont ces classes prendront une instance, sans jamais se soucier de quelle est la classes concrète de cette instance. Tout ce qui importe, c'est qu'on peut appeler envoyerMessage() dessus.

Merci pour ta réponse, mais je vais sans doute dire une grosse bêtise, tu parles d'un objet Messager et d'interface Messager.... je croyais qu'on pouvais pas instancier un objet avec une interface ???

Comme dit précédemment, une interface est un contrat, dit autrement, c'est ce qu'on va montrer à l'utilisateur, un exemple concret:

Ceci est un module physique pour un moteur de jeu (j'ai retiré les commentaires et la licence(mit) pour plus de lisibilité, le code original est ici : https://github.com/yildiz-online/module-physics ).
Ce module doit interagir avec le moteur de jeu, qui va lui donner des instructions(faire une mise à jour du monde, calculer les collisions, stopper ou démarrer le moteur, et l'utilisateur de la classe, lui n'a pas à utiliser ces instructions, il n'en a pas le droit:
(La classe est abstraite mais ne t'en préoccupe pas, ce n'est pas important ici)

On voit tout de suite qu'il faut connaître à l'avance tous les types qu'on va utiliser alors qu'avec l'interface (à comprendre comme une capacité à faire quelque chose) ça se résumerait à
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
for (Deplaçable2D mobile : (List<Deplaçable2D>)mesObjetsDeplaçable2D)
{
mobile.tournerAGauche();
}
avec comme énorme avantage qu'on pourra ajouter par la suite un objet "Bateau", "Velo", etc... sans avoir à reprendre ce code (alors que dans l'autre version, il faudra rajouter nos else if (... instanceof ...)).

Encore une fois, l'interface sert à voir un objet non pas sous la forme de son implémentation mais sous la forme d'une capacité à faire quelque chose.

Et j'en rajoute une couche

Merci, vous assurez, mais vous savez c'est le week end vous étiez pas obligés de répondre si rapidement. C'est quand même plus clair pour moi avec des exemple, concernant l’intérêt des interfaces. J'ai juste une impression bizarre, comme dit plus haut, j'ai l'impression que vous instanciez des objets de la classe interface, la c'est un "détail" que je comprend pas.

Je vais essayer de trouver des exercices nécessitant les interfaces, en pratiquant ça sera peut être plus clair et je vous ferai pas perdre votre temps. Et désolé si j'ai dis de grosses bêtises

[thelvin]

Euh, certes on ne peut pas instancier un objet rien qu'avec une interface.

Mais le principe d'une interface c'est pas d'avoir écrit une interface et de se dire "waouh, je suis fier d'avoir écrit cette interface, elle est très jolie !"

Le principe d'une interface, c'est que quelqu'un, quelque part, à un moment donné, va écrire une classe qui implémente cette interface. Et donc il sera possible de faire des instances de cette classe.

Qui, donc, seront des objets utilisables partout où on essaie d'utiliser cette interface.

[OButterlin]

Et sinon, si vraiment tu ne vois pas la différence entre une interface et une classe abstraite, on peut résumer comme ceci :
- la classe abstraite sert à factoriser un code commun à plusieurs classes (on se pose la question du "comment")
- l'interface sert à signaler qu'une classe à la capacité de faire quelque chose (on se fiche du "comment")

Ce sont 2 choses très différentes

Et bien sûr, faire une interface pour une seule classe n'a, à priori, pas plus d'intérêt que de faire une classe abstraite qui ne serait étendue que par une seule classe...

[PhilippeGibault]

Je rappelle que la bible des bonnes pratiques en Java (https://www.amazon.fr/Effective-Java...4WWRMMK55RMR9N) explique qu'il faut mieux utiliser une Interface plutôt qu'une classe Abstraite.

Tout a été dit dans la discussion: Une Interface est un contrat. Du coup (car la bible dit aussi qu'il faut définir un objet par son interface), on interagit avec un contrat.
On respecte le principe suivant (dit d'inversion de contrôle): Je sais ce que tu fais, mais je ne veux surtout pas savoir comment tu est codé.

L'exemple le plus pratique est la BDD. On peut lire, écrire, modifier...
Grace à l'interface, je sais que je pourrais lire, écrire, ...
A moi d'injecter la bonne implémentation suivant la BDD cible (Oracle, MySQL...).

D'ailleurs, les interfaces marchent bien avec l'injection de dépendance (https://fr.wikipedia.org/wiki/Inject...C3%A9pendances) (une autre bonne pratique).

La classe Abstraite elle, est plutôt adapté pour factoriser le code, et utiliser ce que l'on appelle le Template Method (https://fr.wikipedia.org/wiki/Patron_de_m%C3%A9thode).
Ça évite d'écrire plusieurs fois le même code, donc de factoriser et c'est mieux pour la maintenance.