Discussion :

[mimish]

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

[Robin56]

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.

[Mathieu.J]

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

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

[mimish]

Donc ça n'existe pas

Merci à vous

[Robin56]

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.

[tchize_]

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 :

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

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 :

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

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 :

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

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 :

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

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

Code :

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

1
2
3
public class Machin implements Truc {
    // methodes de Truc
}

Code :

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

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

Code :

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

1
2
3
4
 
Truc t = .....;
if (t instanceof Bidule)
   ((Bidule)t).bidule();

[adiGuba]

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 :

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

1
2
3
4
5
6
7
8
9
interface Exemple {
 
	public void methodeStandard();
 
	public void methodeOptionnel() default {
		throw new UnsupportedOperationException("methodOptionnel");
	}
 
}

a++

[thelvin]

Ç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.

[hwoarang]

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.

[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?

[thelvin]

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.