Discussion :

[wafiwafi]

Bonjour,
Il arrive qu’une classe utilise une méthode de l’API java avec la condition que la classe implémente une interface …
J’ai remarqué deux aspects :
1- La classe implémente la méthode et là tout va bien ! Place au polymorphisme
2- la classe utilise directement la méthode (exemple : la méthode clone de l’interface cloneable)ou en core (ListIterator.) et là tout va mal !! car on a toujours appris que la classe a obligation d’implémenter la méthode de l’interface. LE CODE dans ce dernier cas est déjà prévu !??
Merci à vous

[paissad]

Bonjour,
j'ai du mal à bien suivre :/
Par hasard, je ne sais pas vraiment grand chose de ta situation, ... mais la classe qui implémente l'interface est une classe abstraite, alors cette classe là n'est pas obligé d'implémenter les méthodes de l'interface.
Mais bon, ... je ne vais pas trop continuer, je ne comprends pas trop ta question
Cordialement,

[professeur shadoko]

(exemple : la méthode clone de l’interface cloneable)

L'interface Cloneable ne définit pas la méthode clone()!
C'est très particulier: voir la doc.

[wafiwafi]

Merci pour vos réponses.
Je vais être très clair!

Il arrive qu’une classe concrète utilise une méthode de l’API java avec la condition que la classe implémente une interface. Il arrive également que cette méthode ne soit pas implémentée par la classe.

Exemple :
Prenons une classe A qui implémente une interface B.
a est un objet de A.
m() est une méthode qui peut être appelée par un objet si la classe de ce dernier implémente le B.
je peux donc faire :
a.m()
ma question est :
il arrive d'appeler cette méthode m() sur a (en sachant ce qu'elle fait à priori) sans que la classe A l'implémente. C'est du tout fait (code).
Alors qu'on a appris que si on utilise une méthode d'une interface, on doit obligatoirement l'implémenter!

Désolé si c'est encore flou, vous me le faites savoir. vos avis sont les bienvenus.

[thelvin]

il arrive d'appeler cette méthode m() sur a (en sachant ce qu'elle fait à priori) sans que la classe A l'implémente.

Donne un exemple pour ça aussi.

Il n'est pas nécessaire que A implémente la méthode m(). Par exemple, il pourrait y avoir une classe BImpl entre A et B :
- BImpl implémente B
- A étend BImpl
- BImpl implémente m().
Dans ce cas ça marche, puisque A hérite de m() par BImpl, A n'a pas besoin d'implémenter la sienne.

Autre possibilité : si A est abstraite. Dans ce cas, elle n'a pas besoin d'implémenter m(), mais les classes concrètent qui en héritent, elles, y seront obligées.

À propos de Clonable/clone() : c'est autre chose. Clonable/clone() sont un cas particulier, qui vient des premières versions de Java. Clonable ne demande d'implémenter aucune méthode. Et clone() est implémenté directement par Object, donc appelable sur tous les types objets. (En tout cas ça compilera. Mais ça fera une CloneNotSupportedException pour ceux qui n'implémentent pas Clonable.)

[professeur shadoko]

À propos de Clonable/clone() : c'est autre chose. Clonable/clone() sont un cas particulier, qui vient des premières versions de Java. Clonable ne demande d'implémenter aucune méthode. Et clone() est implémenté directement par Object, donc appelable sur tous les types objets. (En tout cas ça compilera. Mais ça fera une CloneNotSupportedException pour ceux qui n'implémentent pas Clonable.)

pas tout à fait: Cloneable est ce qu'elle est non pas parce que c'est une antiquité mais parce qu'elle illustre un problème particulier: un contrat lié à une méthode protected (les interfaces sont des contrats sur des méthodes publiques uniquement). On ne peut pas appeler clone sur n'importe quel objet: pour certains ça ne se compilera pas (tant qu'ils ne sont pas doté d'une méthode clone accessible par le code client). Il y a là un concentré de toutes les subtilités des méthodes protected et de leur utilisation.

[deathness]

pas tout à fait: Cloneable est ce qu'elle est non pas parce que c'est une antiquité mais parce qu'elle illustre un problème particulier: un contrat lié à une méthode protected (les interfaces sont des contrats sur des méthodes publiques uniquement). On ne peut pas appeler clone sur n'importe quel objet: pour certains ça ne se compilera pas (tant qu'ils ne sont pas doté d'une méthode clone accessible par le code client). Il y a là un concentré de toutes les subtilités des méthodes protected et de leur utilisation.

Pour moi ce stratagème est un peu à oublier, et est maintenant obsolète.

[paissad]

Je pense que je comprends ce que tu veux dire.
Cependant, il faut savoir que lorsque tu arrives à obtenir une instance 'a' d'objet de type A, c'est parce que tu as fait un A a = new A(); ou un A a = new C(); ou C extends A ....
Mais sachant que pour faire un new() (c'est à dire créer une instance) il faut utiliser une classe concrète ... alors cela signifie que la méthode m a été implémentée.
Tu ne pourras pas faire new() sur une interface ou classe abstraite ...
Mais, oui mais mais mais:
si tu fais directement

Code :

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

1
2
A a;  // ou A a = null;
a.m();

ça ne générera pas d'erreur de compilation, mais d'exécution car tu remarques que 'a' n'est ni instancié ou quoi que ce soit qui puisse rendre valable l'utilisation de la méthode m();
par contre, ceci est ok !A a = new C(); a.m(); si C est une classe concrète.
Conclusion:
* si A est une classe concrète => ça signifie que la méthode m() est implémentée ...
* si A n'a pas implémenté m(); alors A n'est pas une classe concrète !