Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

La beauté des fermetures


Sujet :

C#

  1. #1
    Rédacteur/Modérateur

    La beauté des fermetures
    Bonjour,

    Cette discussion est destinée à recueillir vos commentaires sur l'article La beauté des fermetures (traduction de l'article The Beauty of Closures de Jon Skeet).

    Un de ces jours, j’aimerais écrire sur mon blog à propos des diverses propositions pour les fermetures en Java 7. Cependant, quand j’ai commencé à écrire ce billet, j’ai réalisé qu’il était difficile de commencer sans une introduction aux fermetures. Au fil du temps, cette introduction est devenue tellement longue que j’ai eu peur de perdre la plupart de mes lecteurs avant d’arriver à la partie concernant Java 7. Puisque le chapitre 5 du livre (C# in Depth, NdT) traite essentiellement des méthodes anonymes et de comment elles apportent les fermetures à C#, il m’a semblé approprié d’écrire cet article ici (sur le site csharpindepth.com, NdT).

    La plupart des articles concernant les fermetures sont écrits en termes de langages fonctionnels, car ceux-ci tendent à mieux les supporter. Cependant, c’est aussi précisément pourquoi il est utile d’écrire un article qui traite de comment elles apparaissent dans des langages orientés objet plus traditionnels. Il y a des chances que si vous programmez dans un langage fonctionnel, vous les connaissez déjà. Cet article traitera de C# (1, 2 et 3) et de Java (avant la version 7).

  2. #2
    Membre actif
    Bonjour,
    Il aurait été pertinent de décliner les exemples avec Java 8 puisque les lambda arrivent dans cette version qui est pour mars ou avril.

    Sinon bon article, merci.
    Bonne journée

  3. #3
    Rédacteur/Modérateur

    Citation Envoyé par tralloc Voir le message
    Il aurait été pertinent de décliner les exemples avec Java 8 puisque les lambda arrivent dans cette version qui est pour mars ou avril.
    Certes... mais je me suis contenté de traduire, je ne pouvais pas ajouter des choses que l'auteur n'avait pas écrites

    L'article a été écrit il y a au moins 2 ans il me semble, donc à l'époque les lambdas de Java 8 n'étaient pas encore finalisées...

  4. #4
    Membre actif
    Ok, c'est bien dommage.
    Mais si tu as du courage pour le faire, tu peux rajouter quelque chose en disant que c'est un ajout de ta part. Ca se fait, non ?

  5. #5
    Rédacteur/Modérateur

    Citation Envoyé par tralloc Voir le message
    Mais si tu as du courage pour le faire, tu peux rajouter quelque chose en disant que c'est un ajout de ta part. Ca se fait, non ?
    Oui je suppose que ça pourrait se faire, en tant que "note du traducteur"... mais d'un autre côté, je ne connais pas très bien Java, donc je risque de dire des bêtises

  6. #6
    Membre actif
    Dans le point 5 " Comparaison des stratégies de capture : puissance contre complexité", l'auteur indique qu'il n'est pas possible en java d'avoir facilement le comportement attendu par défaut en C#, à savoir, d'effectuer plusieurs fois l'action sur une même variable (et non sa valeur).

    Dans le cas présenté, afficher 10 fois la valeur final du compteur: "10".

    Le comportement similaire en java est certes un peux plus complexe, mais il est farfelu de proposer une solution basé sur des tableau pour capturer les références...

    Le constat est simple: en java, la référence doit être "final". La solution, et donc de simplement créer un objet "final" qui va encapsuler l'objet à manipuler.

    Pour un compteur, AtomicInteger remplis ce rôle (même s'il n'est pas du tout prévu pour ça à la base).

    Le code est donc le suivant, et fonctionne comme le cas initial présenté en C#:

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    // Construire d’abord une liste d’actions
    List<Runnable> actions = new ArrayList<Runnable>();
     
    for (final AtomicInteger counter = new AtomicInteger(0); counter.get() < 10; counter.getAndIncrement()) {
     
         actions.add(new Runnable() {
              public void run() {
                   System.out.println(counter.get());
              }
         });
    }
     
    // Puis les exécuter
    for (Runnable action : actions) {
         action.run();
    }

  7. #7
    Rédacteur

    Un détail : les accolades ouvrantes dans les blocs de code en Java sont placées à la ligne suivante et non à la fin de la ligne.
    Thierry Leriche-Dessirier
    Consultant Java JEE Web Agile freelance
    Rédacteur pour Developpez
    Professeur de Génie Logiciel à l'ESIEA

    Site : http://www.icauda.com / Linked'in : http://www.linkedin.com/in/thierryler / Twitter : @ThierryLeriche

  8. #8
    Rédacteur/Modérateur

    Citation Envoyé par Sebajuste Voir le message
    Le constat est simple: en java, la référence doit être "final". La solution, et donc de simplement créer un objet "final" qui va encapsuler l'objet à manipuler.
    Je pense qu'il suggérait un tableau pour éviter d'avoir à créer une classe spécifique pour ça. Dans le cas d'un entier, tu peux effectivement utiliser AtomicInteger, mais il n'y a pas forcément d'équivalent standard pour d'autres types... Idéalement je suppose qu'il faudrait créer une classe Box<T> qui sert à ça (mais si je me souviens bien, en Java on ne peut pas utiliser les types primitifs comme arguments de type générique, si ?)

  9. #9
    Rédacteur/Modérateur

    Citation Envoyé par thierryler Voir le message
    Un détail : les accolades ouvrantes dans les blocs de code en Java sont placées à la ligne suivante et non à la fin de la ligne.
    C'est juste... Je me suis fait la remarque en traduisant, mais comme l'auteur l'avait écrit comme ça, j'ai laissé comme c'était.

    Pour la petite histoire : Jon Skeet est reconnu comme l'un des meilleurs experts de C#, mais pourtant il travaille... chez Google comme développeur Java !

  10. #10
    Rédacteur

    OK je n'avais pas vu que c'était une traduction
    Thierry Leriche-Dessirier
    Consultant Java JEE Web Agile freelance
    Rédacteur pour Developpez
    Professeur de Génie Logiciel à l'ESIEA

    Site : http://www.icauda.com / Linked'in : http://www.linkedin.com/in/thierryler / Twitter : @ThierryLeriche

  11. #11
    Membre actif
    Citation Envoyé par tomlev Voir le message
    mais si je me souviens bien, en Java on ne peut pas utiliser les types primitifs comme arguments de type générique, si ?
    Effectivement, mais cela n'est plus un problème depuis l'outboxing.

    Il suffit de typer la classe Box<> avec la classe wraper adéquate (Integer, Byte, Long, Float, etc...). Le "transtipage" avec le type primitif est transparent.

###raw>template_hook.ano_emploi###