Discussion :

[gzgt7]

bonjour tout le monde ,

bon voila ce que j'ai compris concernant les interfaces :
tout d’abord c'est une class 100% abstraite
c'est une sorte de contrat ou on décris un comportement et on s'en fou de son implémentation
ca nous aide aussi a avoir plusieurs comportement car on peux implémenté plusieurs interfaces
j'ai compris aussi que elle nous aide la ré-utilisabilité de nos class

ce que je n'arrive pas a comprendre ou a voir c'est cette flexibilité je ne comprend pas comment les interfaces nous aide sur ce point ,
car j'ai lu que qu'on on veux modifier notre class si on a utiliser des interfaces ca sera plus simple c'est sur point que je voudrais comprendre .
je vous remercie d'avance .

[Pill_S]

tout d’abord c'est une class 100% abstraite

oui, mais c'est de moins en moins vrai... cf. "implém par défaut" des interfaces, dans Java 8

c'est une sorte de contrat ou on décris un comportement et on s'en fou de son implémentation

oui c'est ça. c'est même la définition d'une interface, c'est "l'expression d'un contrat"

ca nous aide aussi a avoir plusieurs comportement car on peux implémenté plusieurs interfaces

moui, certains utilisent aussi un raccourci très imprécis en disant que ça permet de l'héritage multiple, mais ce n'est pas vrai. Implémenter plusieurs interfaces, c'est dire que l'on respecte plusieurs contrats.

j'ai compris aussi que elle nous aide la ré-utilisabilité de nos class

pas forcément... ça n'aide pas à réutiliser une classe, ça permet surtout de "s'interfacer" avec des API différentes (genre si j'implémente "Comparable", alors je peux utiliser mes instances dans des API telles que "Arrays.sort")

ce que je n'arrive pas a comprendre ou a voir c'est cette flexibilité je ne comprend pas comment les interfaces nous aide sur ce point ,

car j'ai lu que qu'on on veux modifier notre class si on a utiliser des interfaces ca sera plus simple c'est sur point que je voudrais comprendre .

euh nan pas vraiment d'accord, ça va pas forcément simplifier. ce que cela permet surtout, c'est de se découpler (découpler = s'isoler de façon logique d'un type particulier) complètement d'une implémentation spécifique, en voyant les objets tels que des "concepts" abstraits minimalistes (si je reprend mon exemple de Comparable, si l'on venait à changer la signature de Comparable - ce qui n'arrivera jamais -, le seul impact serait sur l'implémentation des méthodes compareTo - le reste de l'objet ne serait pas impacté, puisque tous les utilisateurs de ce Comparable ne voient que ce qui est exposé par Comparable - ils ne voient pas de Carottes ou de Choufleur, mais que des Comparable, donc aucun risque qu'ils s'appuient sur des comportements spécifiques de Carotte ou Choufleur)

Enfin c'est difficile à expliquer, et au début on a du mal à comprendre ce que cela amène, mais avec le temps ça devient de plus en plus clair. La FAQ Java l'explique peut-être mieux que moi... http://java.developpez.com/faq/java?...-une-interface

[joel.drigo]

Salut,

On peut induire une certaine flexibilité par certains usages.

Premier cas de flexibilité : le fait de typer l'objet par l'interface.
Si tu écris :

Code :

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

1
2
List<String> maList = new ArrayList<>();
// puis du code pour traiter maList (en passant donc par l'interface)

Tu peux à tout moment décider de remplacer new ArrayList<>() par new LinkedList<>(). Sans avoir à modifier le reste du code, qui ne passe que par l'interface. Si tu avais typé ArrayList, ce n'est pas que tu aurais nécessairement à modifier le code, mais cela peut être possible, si tu as utilisé des méthodes spécifiques de ArrayList (par exemple trimToSize()).
Mieux encore si :

Code :

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

1
2
3
4
5
6
Iterable<String> method() {
          // du code qui contruit une liste
         ArrayList<String> list = new ArrayList<>();
         // ...
         return list;
}

Tu peux à tout moment décider qu'une ArrayList n'est pas le plus judicieux pour implémenter l'ltérateur, et qu'un Set sera plus efficace, ou autre chose (un tableau par exemple), ou autre raison (peu importe en fait). Et tout le code qui appelle ta méthode reste inchangé. Non seulement ça t'évite de modifier tout le code en question, mais si ton code est diffusé sous forme d'API, ceux qui l'utilisent ne seront pas eux non plus obligés de modifier tout leur code si tu as envie de changer l'implémentation à un moment donné.
Lorsqu'on fait ce genre de méthode, il faut toujours se poser la question de quel contrat on veut permettre l'utilisation. Ici, on a décidé que le but était de juste de parcourir une liste d'éléments. Mais si on veut par exemple tout d'un coup permettre de connaitre le nombre d'éléments, on peut remplacer Iterable par Collection, et ce, sans impact sur le code appelant déjà existant (ni même d'ailleurs le code de la méthode en l'occurance). Simplement, ce code existant n'utilisera que la capacité lié au contrat d'Iterable, alors que le nouveau code pourra utiliser celui induit par Collection (qui étend Iterable).


On peut aussi voir pratiquement cette flexibilité par exemple avec les renderers ou les éditeurs, dans les composants Swing. Par exemple, pour définir un éditeur sur une JTable, on doit implémenter l'interface TableCellEditor. Peu importe comment est fait l'éditeur, tant que le contrat de l'interface est respectée, la JTable l'utilisera pour permettre l'édition d'une cellule. L'éditeur peut être aussi bien un champ de saisie de texte, une checkbox, une combo, ou n'importe quoi d'autres. Et tu peux changer l'éditeur comme tu veux, après coup. Si tu as fais un éditeur pour saisir un nom de fichier, et que tu te dis par la suite, j'ai envie d'ajouter un bouton "Browse" pour afficher un JFileChooser, tu peux.
Et ceci est vrai si tu étends la classe : elle continue d'implémenter l'interface, et tu peux redéfinir les méthodes de l'interface pour adapter le comportement à ton cas spécifique.

[gzgt7]

euh nan pas vraiment d'accord, ça va pas forcément simplifier. ce que cela permet surtout, c'est de se découpler (découpler = s'isoler de façon logique d'un type particulier) complètement d'une implémentation spécifique, en voyant les objets tels que des "concepts" abstraits minimalistes (si je reprend mon exemple de Comparable, si l'on venait à changer la signature de Comparable - ce qui n'arrivera jamais -, le seul impact serait sur l'implémentation des méthodes compareTo - le reste de l'objet ne serait pas impacté, puisque tous les utilisateurs de ce Comparable ne voient que ce qui est exposé par Comparable - ils ne voient pas de Carottes ou de Choufleur, mais que des Comparable, donc aucun risque qu'ils s'appuient sur des comportements spécifiques de Carotte ou Choufleur)

merci pour votre repense ce que je comprend quand on parle de découpler c'est le principe de la responsabilité unique en quelque sorte mais votre exemple je lai pas compris,si vous pouvez mon donner un exemple plus simple ou l'interface nous permet de découpler,merci d'avance

[gzgt7]

je vous remercie pour votre repense TRÈS précise merci beaucoup

Code :

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

1
2
List<String> maList = new ArrayList<>();
// puis du code pour traiter maList (en passant donc par l'interface)

Tu peux à tout moment décider de remplacer new ArrayList<>() par new LinkedList<>(). Sans avoir à modifier le reste du code, qui ne passe que par l'interface. Si tu avais typé ArrayList, ce n'est pas que tu aurais nécessairement à modifier le code, mais cela peut être possible, si tu as utilisé des méthodes spécifiques de ArrayList (par exemple trimToSize()).
Mieux encore si :

Code :

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

1
2
3
4
5
6
Iterable<String> method() {
          // du code qui contruit une liste
         ArrayList<String> list = new ArrayList<>();
         // ...
         return list;
}

Tu peux à tout moment décider qu'une ArrayList n'est pas le plus judicieux pour implémenter l'ltérateur, et qu'un Set sera plus efficace, ou autre chose (un tableau par exemple), ou autre raison (peu importe en fait). Et tout le code qui appelle ta méthode reste inchangé. Non seulement ça t'évite de modifier tout le code en question, mais si ton code est diffusé sous forme d'API, ceux qui l'utilisent ne seront pas eux non plus obligés de modifier tout leur code si tu as envie de changer l'implémentation à un moment donné.
Lorsqu'on fait ce genre de méthode, il faut toujours se poser la question de quel contrat on veut permettre l'utilisation. Ici, on a décidé que le but était de juste de parcourir une liste d'éléments. Mais si on veut par exemple tout d'un coup permettre de connaitre le nombre d'éléments, on peut remplacer Iterable par Collection, et ce, sans impact sur le code appelant déjà existant (ni même d'ailleurs le code de la méthode en l'occurance). Simplement, ce code existant n'utilisera que la capacité lié au contrat d'Iterable, alors que le nouveau code pourra utiliser celui induit par Collection (qui étend Iterable).

je suis tout a fait d'accord avec ce que vous dite mon problème est que pour le moment si je vais écrire ,j'aurais pas cette vision ou je vais me dire que je vais utiliser une interface car a chaque je me dis qu'avec de l’héritage et du polymorphisme avec un caste je pourrais faire le même travaille qu'une interface
donc ma question est comment l'utilisation d'une interface nos procure cette flexibilité que l’héritage et polymorphisme n'est pas en mesure de nous satisfaire ,ça peux vous paraitre bête mais je voudrais vraiment avoir cette vision des choses
je vous remercie .

[Nico02]

Salut,

Ce n'est pas qu'un interface est nécessairement utilisée pour palier à un manque fonctionnel dont pourrait souffrir l'héritage. C'est simplement que c'est une vision différente des choses.

Comme tu l'as dit, une interface est un contrat que ce doit de respecter un objet. La différence c'est que l'interface elle se moque complètement de savoir qu'elle manipule un objet de type A et de type B.

Ce qui l’intéresse c'est que cet objet implémente une fonction dont elle est sûre de pouvoir se servir.

Je vais reprendre un exemple que j'ai vu passer sur un autre topic.

Imagines que tu codes en swing des formes géométrique qui bougent dans une frame. Tu vas avoir une classe abstraite Shape pour définir ces formes, puis une spécialisation pour dire que tu as des carré, des triangles etc..

Pour les faire bouger il te faut une fonction move() qui sera différente selon les formes. Alors effectivement tu pourrais la mettre dans ta classe abstraite et la faire hériter pour être redéfinie dans chaque sous classe. Mais tu pourrais aussi créer une interface Movable qui va définir cette fonction.

La différence c'est que le code qui va manipuler ces objets, lui il n'a aucune utilité de savoir qu'il fait bouger des Shape. Lui ce qu'il veut c'est des objets qui implémente Movable. Les autres fonctions de l'objet il n'en a rien à faire. Et puis si demain tu veux créer une classe ShapeDeuxiemeDuNom qui a une logique différente de la première. Le code qui gère les déplacements lui il fonctionnera toujours sans avoir besoin de le modifier.

Donc voila, pour moi c'est une question de vision des choses. Est-ce que tu cherches à manipuler les objets en question, ou simplement exploiter des comportements qu'ils définissent. Il n'y a pas obligatoirement de bonne réponse, et avec le temps tu auras ta propre façon de voir les choses.

Cdt.

[adiGuba]

Salut,


L'interface permet de décrire un contrat, sans prendre en compte une implémentation spécifique.
Et c'est cela qui donne plus de flexibilité car tu n'imposes pas un type précis.


Par exemple si tu écris une méthode comme ceci :

Code :

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

1
2
3
4
5
public void sendMail(ArrayList<String> emails) {
    for (String email : emails) {
        System.out.println("send email to : " + email);
    }
}

Ta méthode n'est pas très flexible car elle impose un type très précis (ArrayList).
Si tu as une LinkedList tu devras créer une copie dans une ArrayList pour utiliser la méthode.
Pourtant il n'y a pas vraiment de raison d'utiliser un type aussi précis dans ce cas là.


Donc tu peux grandement améliorer cela rien qu'en utilisant l'interface List à la place d'ArrayList (comme LinkedList ou Vector par exemple).
Et même List propose un contrat bien plus large que ce dont tu as besoin (List = Collection ordonnée par index), donc tu peux encore élargir l'usage en utilisant le type Collection et rendre ta méthode utilisable avec encore plus de type, comme HastSet, BlockingQueue, etc.

Tu peux même continuer encore plus loin : en fait ton seul besoin est de parcourir un ensemble d'élément, et c'est justement le rôle d'Iterable :

Code :

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

1
2
3
4
5
public void sendMail(Iterable<String> emails) {
    for (String email : emails) {
        System.out.println("send email to : " + email);
    }
}

Ta méthode est désormais utilisable avec une infinité de structures de données, que ce soit de l'API standard ou pas, sans avoir à rien faire de spécifique.
C'est là qu'est la flexibilité.


En utilisant une interface, tu déclares le comportement dont tu as besoin, sans forcément imposer une implémentation spécifique.

C'est la même différence qu'il y a entre "j'ai à tout prix besoin d'une voiture", et "j'ai à tout prix besoin d'une Citroën DS4 1.6 HDi 115".



a++

[gzgt7]

La différence c'est que le code qui va manipuler ces objets, lui il n'a aucune utilité de savoir qu'il fait bouger des Shape. Lui ce qu'il veut c'est des objets qui implémente Movable. Les autres fonctions de l'objet il n'en a rien à faire. Et puis si demain tu veux créer une classe ShapeDeuxiemeDuNom qui a une logique différente de la première. Le code qui gère les déplacements lui il fonctionnera toujours sans avoir besoin de le modifier.
Cdt.

salut ,
je commence a bien comprendre les choses ,

ce que j'ai bien compris c'est que dans votre exemple si dans mon code principale j'ai utiliser mais objet (supposant triangle ,un carré , rectangle) qui hérite de shape si j'utilise dans mon code du polymorphisme c'est vrais que la mon code est lié a shape alors qu'il na pas besoin de ca car il fait que bouger mais objets et si je change ma class shape en shape2 par exp je devrais changer dans tout mon code shape par shape2 ,

mais si je laisse le même nom pour ma classe et je change d'autre chose a part ca je pense que ca ne vas pas affecté mon programme principale non (je veux juste être sur )?

[gzgt7]

salut ,

donc adiGuda , je pense que j'ai compris je vais essayer de revoir tout cas et vous donner une repense définitif .
merci ^^