On Wed, 6 Apr 2011 18:42:02 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 6 Apr 2011 18:10:42 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Dans ce cadre ApplicationConfig n'est pas auto-suffisant car non JavaBeans et donc non écoutable :(
Une solution serait peut-etre de faire de l'heritage par delegation. Et donc peut-etre de mettre la classe ApplicationConfig final (arg, c moi qui est dit ca, beurk :() :( il l'a dit ;)
Dans les applications ont crée un objet qui encapsule le ApplicationConfig. On peut donc le recuperer a tout moment (pour le passer a une librairie par exemple). On a la main complete sur notre objet, on peut le rendre completement bean avec des propertyChange.
class MaConfig {
ApplicationConfig config;
ApplicationConfig getApplicationConfig() { return config }
String getOption(MesOtions option) { return config.getOption(option); }
String getMonOption1() { return getOption(MesOptions.MON_OPTION1); }
File getMonOption2() { return getOptionAsFile(MesOptions.MON_OPTION2); } }
Y'a plus qu'a ajouter les propertyChange et autre sur cette objet.
ApplicationConfig avait déjà du pcs qui traine, on peut peut-être s'appuyez directement dessus ou bien complètement le supprimer.
des remarques sur cette approche ?
Moi ca me va très bien :) La délégation parait bien indiqué, <joke> du coup on va pouvoir créer une superbe classe FinalApplicationConfig qui délègue a ApplicationConfig et qui gère les pcs tout comme il faut </joke> -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com