Bon, à la demande d'au moins un lecteur, nous voilà parti pour un voyage - dont personne ne reviendra indemne, qui devrait nous amener sur la route du ConfigurationStore. Avant de pouvoir 'latteindre, il y a toutefois quelques obstacles à passer.
Le premier, auquel on s'attaque aujourd'hui, est parfaitement adapté en cette période d'oraux du bac, ils 'agit de quelques rappels sur les PropertyChangeEvent/ PropertyChangeListener/ PropertyChangeSupport. Il vaudra surtout pour les développeurs JEE, qui ne connaissent hélas pas vraiment bien tout ça, ni d'ailleurs le fameux package ajouté en Java 1.4.

https://gist.github.com/1053851En fait, il s'agit de simples rappels, que vous pourrez retrouver dans le trail Java Beans chez Oracle.Donc, quand vous faites du Java, la plupart du temps, vous faites des beans (enfin, si vous n'utilisez pas de propriétés avancées, remarquez, si c'est le cas, je ne vois même pas pourquoi vous lisez cet article ... peut-être pour la fin ...). Un bean, c'est quoi ? une simple classe avec des attributs qui ont des getters et des setters. Facile, non ? Par exemple, cette classeOui, je sais, il ne respecte pas trop les conventions de code habituelles, mais c'est pour le rendre un peu plus court à lire.Donc, ce bean dispose d'un champ "name", qui est également visible comme une propriété de JavaBean (par exemple via un associé), puisqu'il dispose d'un getter et d'un setter. Jusque-là, rien de nouveau sous le soleil.Supposons, pour la beauté du geste, que vous développez une application Swing dans laquelle vous avez un JLabel qui affiche ce champ name et un JTextField pour entrer ce champ name. la grosse question, c'est "comment faire pour synchroniser les contenus de ces deux champs ? Vous n'allez pas invoquer myLabel.setText(myTextField.getText()) quand l'utilisateur change le texte, hein ? Non. Comme vous respectez le modèle MVC, votre JTextField aura un modèle qui rafraîchira votre * quand son contenu change, et vous aurez également un lien qui met à jour le   JTextField quand votre * change. Mais pour ça (c'est assez trivial, et ça ne m'intéresse pas), il faut que votre * soit capable de dire "hé, mon champ name a changé de valeur". Et c'est là que PropertyChangeEvent, PropertyChangeSupport et PropertyChangeListener vont vous servir. Si votre * initial devient celui-ci :

https://gist.github.com/1053852Oui, c'est plus long.Mais avec ça, quand la valeur de "name" change, un événement est envoyé à tout ceux qui veulent l'écouter.Et cet évement, il dit biend es choses à ceux qui savent l'écouter : * Il donne sa source (c'est-à-dire l'objet  ** modifié) * Il donne le nom de la propriété qui a changé (dans notre cas, "name") * Il donne l'ancienne valeur de la propriété * Et enfin la nouvelle valeur de la propriété.Avec ça, on peut faire bien des choses. La plus facile est évidement de changer la valeur de notre JLabel  . Mais on peut aussi "facilement" implémenter, par exemple, un système de persistence de nos objets (je l'ai déja fait, et c'était assez facile d'exécuter une requête dans un PropertyChangeListener). On peut aussi "facilement" implémenter un undo/redo au niveau de notre modèle. C'est exactement la même chose que la persistance, avec une différence sur le stockage des modifications. On peut enfin "facilement" implémenter une collection qui envoie des événements quand son contenu change. Mais ça, ce sera pour la prochaine fois.