août
2006
Un article de adiGuba
J’en ai déjà parlé dans mon message précèdent concernant le futur C# 3, mais j’ai peur que certains aient un peu « sauté » le sujet…
J’y parlais justement d’un document d’étude concernant l’intégration de closures dans Java : Closures for Java [PDF] (en anglais bien sûr).
Les closures ? Qu’est-ce que c’est ?
En français on appellerais plutôt cela des méthodes anonymes, et cela se rapproche (en partie) des pointeurs de fonctions du C/C++.
J’en entends déjà me dire qu’il est inutile d’intégrer cela en Java, puisqu’on peut utiliser des interfaces pour cela, couplé avec des classes anonymes.
Pourtant, cette technique a un gros désavantage : elle est très verbeuse !
Prenons deux exemples :
- L’utilisation de invokeLater() avec un Runnable :
Qu’on utilise pour « passer » un bout de code au thread responsable de l’affichage :SwingUtilities.invokeLater(new Runnable() {
public void run() {
doSometing();
}
}); - L’utilisation d’un Comparator :
Afin de trier un tableau d’objet selon un ordre différent de son ordre naturel, par exemple :Arrays.sort(array, new Comparator<MyObject>() {
public int compare(MyObject o1, MyObject o2) {
return o1.getName().compareTo(o2.getName());
}
});
On retrouve en effet beaucoup d’éléments qui pourrait être évités, que ce soit le nom de la classe, comme la signature complète de la méthode. Même si la plupart des EDI peuvent générer automatiquement ce type de code, il en résulte un code assez lourd et peu lisible…
Qu’apporte donc les closures ?
La possibilité d’utiliser un objet représentant non pas une classe, mais une simple méthode. Par exemple pour déclarer une méthode qui renverrait un int tout en attendant un int en paramètre, on pourrait écrire ceci :
int(int) plus2b = (int x) { return x+2; };
On pourrait même utiliser une forme encore plus courte :
int(int) plus2b = (int x) : x+2;
Il ne nous reste plus qu’à appeler la méthode quand bon nous semble, par exemple :
int res = plus2b(5);
L’intérêt de cette forme concise est encore plus grand si l’on utilise ces closures comme paramètres d’une autres méthodes.
Ainsi, si on reprend les exemples ci-dessus utilisant une classe anonyme afin d’utiliser les closures, on obtient ceci :
-
Arrays.sort(array, (MyObject o1, MyObject o2)
{ return o1.getName().compareTo(o2.getName() } );ou même :
Arrays.sort(array, (MyObject o1, MyObject o2)
: o1.getName().compareTo(o2.getName() ); -
SwingUtilities.invokeLater( () { doSometing(); } );
On se contente du stricte minimum : le type et le nom des paramètres, suivi directement par le code de la méthode : le gain de visibilité est plutôt pas mal !
Cela impliquerait bien sûr pas mal de changement dans le langage, et d’adapter/surcharger plusieurs méthodes (afin qu’elles acceptent des closures à la place des interfaces), mais le jeu en vaut la chandelle…
Je vous invite vivement à lire le PDF pour plus de détail (même si l’étude n’est toujours pas finalisé).
5 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- Difference de performances Unix/Windows d'un programme?
- Classes, méthodes private
- jre 1.5, tomcat 6.0 et multi processeurs
- Recuperation du nom des parametres
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Possibilité d'accéder au type générique en runtime
- [ fuite ] memoire
- Définition exacte de @Override
>> à priori, en français on parle de « clotures ».
Je n’aime pas trop ce terme…
Je pense que « méthodes anonymes » est plus parlant pour les developpeurs Java que « clotures » qui me fait penser à une barrière
à priori, en français on parle de « clotures ».
j’suis pas fan des méthodes anonymes non plus…
Avec les derniers IDE qu’on a je préfère les solutions « verbeuses » qui seront faciles à relire et qui ne sont pas forcément plus longue à taper tellement nous sommes assistés par notre IDE favoris pendant qu’on tape du code
>> Je trouve l’écriture actuelle beaucoup plus lisible, mais ce n’est qu’un avis personnel.
L’habitude peut-être…
>> Sinon, une petite faute qui aurait pu être évitée ;-): « beaucoup d’éléments qui pourrait être éviter » > « beaucoup d’éléments qui pourrait être évités »
Merci c’est corrigé
Perso, je trouve pas ça super clair.
Je trouve l’écriture actuelle beaucoup plus lisible, mais ce n’est qu’un avis personnel.
Sinon, une petite faute qui aurait pu être évitée ;-): « beaucoup d’éléments qui pourrait être éviter » > « beaucoup d’éléments qui pourrait être évités »