Méthodes optionnelles dans les interfaces

Bonjour,

J'aimerai savoir est ce qu'il y a une possiblité de déclarer dans une Inteface des méthodes optionnel, c'est a dire qu'ils ne sont pas obligatoire implémenter dans les classes ?

Merci

Citation:

---

Envoyé par mimish

J'aimerai savoir est ce qu'il y a une possiblité de déclarer dans une Inteface des méthodes optionnel, c'est a dire qu'ils ne sont pas obligatoire implémenter dans les classes ?

---

Non, pas à ma connaissance, après rien ne t'obliges à implémenter le code des méthodes qui ne te servent pas.

Tu peux faire une classe abstraite, qui implémente toutes les méthodes sans rien faire.
Tu étends ensuite ta classe abstraite en redéfinissant seulement la méthode qui t'intéresse.

Cas concret :

MouseListener (Entre autres) <---- MouseAdapter

Citation:

---

An abstract adapter class for receiving mouse events. The methods in this class are empty. This class exists as convenience for creating listener objects.

---

Donc ça n'existe pas :(

Merci à vous

Citation:

---

Envoyé par mimish

Donc ça n'existe pas :(

---

Et pourquoi as tu besoin de ça ? Car à partir du moment ou tu utilises une interface, c'est que tu souhaites certifier aux classes utilisatrices, qu'elles peuvent utiliser les services proposer par l'interface et donc les méthodes disponibles.

Si tu veux rendre optionnel dans le Sens "certaines implémentation auront des fonctionnalités avancée", il y a deux manière de faire

Soit:

créer une interface avec tout, et des methodes du style canXxxxx() ou isXxxxxSupported(). Avec comme convention que l'utilisateur de l'interface devra appeler d'abord ces méthodes pour savoir si les méthodes avancées sont disponible.

Code:

---

1 2 3 4 5 6

public class Machin implements Truc { @override public boolan supportBidule() {return false; } @override public void bidule() {throw new UnsupportedOperationException("Bidule pas supporté"); } }

---

Code:

---

1 2 3 4 5 6

public class MachinBidule implements Truc { @override public boolan supportBidule() {return true; } @override public void bidule() {System.out.println("bidule");} }

---

Code:

---

1 2 3 4

Truc t = .....; if (t.supportBidule()) t.bidule();

---

Soit:
tu travaille avec deux interface: (exemple typique: Graphics et Graphics2 de java)

Code:

---

1 2 3

public interface Bidule extends Truc{ public void bidule(); }

---

Code:

---

1 2 3

public class Machin implements Truc { // methodes de Truc }

---

Code:

---

1 2 3 4 5

public class MachinBidule implements Bidule { @override public void bidule() {System.out.println("bidule");} // methodes de Truc }

---

Code:

---

1 2 3 4

Truc t = .....; if (t instanceof Bidule) ((Bidule)t).bidule();

---

Salut,


Juste pour information : avec Java 8 il sera possible de définir des méthodes optionnelles via les "default methods" (parfois nommé "virtual extension methods" ou "defender methods".


Ces méthodes permettent d'ajouter de nouvelles méthodes dans une interface, sans que les classes filles ne soient obligé de les implémenter.

Exemple (la syntaxe n'est peut-être pas définitive) :

Code:

---

1 2 3 4 5 6 7 8 9

interface Exemple {   public void methodeStandard();   public void methodeOptionnel() default { throw new UnsupportedOperationException("methodOptionnel"); }   }

---

a++

Ça reste pas très intéressant -_-°. L'intérêt d'avoir des méthodes si elles sont pas obligées de marcher, hein...

C'est une construction pas très originale, souvent vue, et qui, de fait, ne simplifie la vie qu'à son auteur et pose des problèmes aux autres.

Ca ressemble beaucoup à de l'heritage multiple ca. Et ca posera les meme problematiques...

Pour en revenir à la question de départ, une interface peut se voir comme un contrat qui permet justement d'imposer que toute classe qui l'implemente ait les fonctions definies dans l'interface. Rendre des fonctions optionnelles serait contraire au principe meme de l'interface.

Il faudrait plutot exposer quel est le probleme exactement mais la solution n'est pas de rendre des fonctions optionnelles.
Mais bon, des solutions ont deja été données sur comment faire. J'ajouterais (dans la categorie bidouille immonde) la possibilité d'utiliser la reflexion pour savoir si la classe possede telle ou telle methode.

Avoir plusieurs interface ou une classe abstraite avec des implémentations vide restent pour moi les meilleures solutions, mais n'est-ce pas plutot à la base un problème de conception?

Citation:

---

Envoyé par deathness

Avoir plusieurs interface ou une classe abstraite avec des implémentations vide restent pour moi les meilleures solutions, mais n'est-ce pas plutot à la base un problème de conception?

---

Si... Comme je l'ai déjà dit, avoir des méthodes qui sont pas obligées de marcher, c'est pas flamboyant, comme logique.