Bonne utilisation de ApplicationConfig
Salut, Ce document est la pour présenté la bonne utilisation de ApplicationConfig d'après moi. Il est la comme base de départ pour trouver la meilleur utilisation possible. Etendre la classe ApplicationConfig dans son programme ou sa librairie est une mauvaise idée, surtout lorsqu'on utilise cette classe en argument de méthode, car on va finir par avoir plusieurs types de ApplicationConfig incompatibles entre elles et on ne pourra plus utiliser ApplicationConfig car il faudra passer par de la recréation dans le bon enfant de ApplicationConfig a partir des properties d'une autre. Pour éviter cela, la bonne façon lorsqu'on utilise ApplicationConfig serait de créer un MesOptions.java et MesActions.java qui seraient des enumerations dans lequel on défini l'ensemble des caractéristiques (nom, description, valeur par defaut, type, alias, ...) Est-ce que quelqu'un voit un inconvénient à cette bonne pratique ? comment ca marcherait ? ======================= Ajout de méthode spécifique pour accéder facilement a une option ---------------------------------------------------------------- methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION); Les enum implanteraient des interfaces spécifiques -------------------------------------------------- L'enum pour les options devrait implanter une interface spécifique avec les méthodes: - getDescription(): String - getValue(ApplicationConfig): String - getAliases:String[] - ... Et le constructeur de l'enum aurait en argument: - String key - String description - String default value - Class type - boolean transient (indique que l'option ne sera jamais sauvé sur disque) - boolean readonly (indique que l'option ne peut pas changer de valeur) - String ... aliases Init de ApplicationConfig ------------------------- plusieurs constructeurs possibles: - new ApplicationConfig(); - new ApplicationConfig(MesOptions.class); - new ApplicationConfig(MesOptions.class, MesActions.class); ... ApplicationConfig config = new ApplicationConfig(...); config.parse(args); config.action(level); Lors du new si les enums sont passées en argument, l'ApplicationConfig les utilise pour s'initialiser Mise en commun de certains besoins ---------------------------------- Du coup, il est possible de mettre par exemple la methode Help dans ApplicationConfig qui retourne la chaine 'usage' a afficher. Ce qu'il reste a faire ---------------------- Il n'y a pas grand chose a faire, vu qu'on a déjà une interface existante pour les options (OptionDef), il manque juste les alias. Et il faut juste le mettre en place de cette façon dans les projets (surtout les libs) qui l'utilise et y penser pour les prochains. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Tue, 5 Apr 2011 17:33:46 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
Salut,
Ce document est la pour présenté la bonne utilisation de ApplicationConfig d'après moi. Il est la comme base de départ pour trouver la meilleur utilisation possible.
Etendre la classe ApplicationConfig dans son programme ou sa librairie est une mauvaise idée, surtout lorsqu'on utilise cette classe en argument de méthode, car on va finir par avoir plusieurs types de ApplicationConfig incompatibles entre elles et on ne pourra plus utiliser ApplicationConfig car il faudra passer par de la recréation dans le bon enfant de ApplicationConfig a partir des properties d'une autre.
Pour éviter cela, la bonne façon lorsqu'on utilise ApplicationConfig serait de créer un MesOptions.java et MesActions.java qui seraient des enumerations dans lequel on défini l'ensemble des caractéristiques (nom, description, valeur par defaut, type, alias, ...)
Est-ce que quelqu'un voit un inconvénient à cette bonne pratique ? Non
comment ca marcherait ? =======================
Ajout de méthode spécifique pour accéder facilement a une option ----------------------------------------------------------------
methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String
Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION);
Les enum implanteraient des interfaces spécifiques --------------------------------------------------
L'enum pour les options devrait implanter une interface spécifique avec les méthodes: - getDescription(): String - getValue(ApplicationConfig): String - getAliases:String[] - ...
Et le constructeur de l'enum aurait en argument: - String key - String description - String default value - Class type - boolean transient (indique que l'option ne sera jamais sauvé sur disque) - boolean readonly (indique que l'option ne peut pas changer de valeur) - String ... aliases
Init de ApplicationConfig -------------------------
plusieurs constructeurs possibles:
- new ApplicationConfig(); - new ApplicationConfig(MesOptions.class); - new ApplicationConfig(MesOptions.class, MesActions.class); ...
ApplicationConfig config = new ApplicationConfig(...); config.parse(args); config.action(level);
Lors du new si les enums sont passées en argument, l'ApplicationConfig les utilise pour s'initialiser
Mise en commun de certains besoins ----------------------------------
Du coup, il est possible de mettre par exemple la methode Help dans ApplicationConfig qui retourne la chaine 'usage' a afficher.
Ce qu'il reste a faire ----------------------
Il n'y a pas grand chose a faire, vu qu'on a déjà une interface existante pour les options (OptionDef), il manque juste les alias.
Et il faut juste le mettre en place de cette façon dans les projets (surtout les libs) qui l'utilise et y penser pour les prochains.
C'est à dire que l'on peut déjà utiliser ApplicationConfig ainsi ? J'ai juste relu le mail 3 fois avant de percuter, mais c'est bon pour moi. Julien
On Tue, 5 Apr 2011 22:23:21 +0200 Julien Ruchaud <julien.ruchaud@codelutin.com> wrote:
Le Tue, 5 Apr 2011 17:33:46 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
Salut,
Ce document est la pour présenté la bonne utilisation de ApplicationConfig d'après moi. Il est la comme base de départ pour trouver la meilleur utilisation possible.
Etendre la classe ApplicationConfig dans son programme ou sa librairie est une mauvaise idée, surtout lorsqu'on utilise cette classe en argument de méthode, car on va finir par avoir plusieurs types de ApplicationConfig incompatibles entre elles et on ne pourra plus utiliser ApplicationConfig car il faudra passer par de la recréation dans le bon enfant de ApplicationConfig a partir des properties d'une autre. Je ne suis pas d'accord dans tous les cas.
Il peut être très bien de pouvoir utiliser ApplicationConfig (une surcharge en fait) comme un Bean, typiquement dans une application finale. Le fait d'avoir des getter et setter c'est souvent plus pratique qu'un helper avec des méthodes statiques. De plus avec un vrai objet de config, on peut aussi avoir une interactions avec des PropertychangeListener et c'est pas mal. Moi je suis vraiment pas convaincu de cette utilisation pour une application finale (en tout pour du swing qui utilise beaucoup la norme JavaBean). L'utilisation ensuite dans une librairie de cette surcharge d'ApplicationConfig ne posera jamais un problème car c'est toujours du ApplicationConfig. Suis-je clair ? Par contre pour les librairies oui il faut bien faire comme ça et donc pour moi y'a pas une manière universelle de faire.
Pour éviter cela, la bonne façon lorsqu'on utilise ApplicationConfig serait de créer un MesOptions.java et MesActions.java qui seraient des enumerations dans lequel on défini l'ensemble des caractéristiques (nom, description, valeur par defaut, type, alias, ...)
Est-ce que quelqu'un voit un inconvénient à cette bonne pratique ?
Non
comment ca marcherait ? =======================
Ajout de méthode spécifique pour accéder facilement a une option ----------------------------------------------------------------
methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String
Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION);
Les enum implanteraient des interfaces spécifiques --------------------------------------------------
L'enum pour les options devrait implanter une interface spécifique avec les méthodes: - getDescription(): String - getValue(ApplicationConfig): String - getAliases:String[] - ...
Et le constructeur de l'enum aurait en argument: - String key - String description - String default value - Class type - boolean transient (indique que l'option ne sera jamais sauvé sur disque) - boolean readonly (indique que l'option ne peut pas changer de valeur) - String ... aliases
Init de ApplicationConfig -------------------------
plusieurs constructeurs possibles:
- new ApplicationConfig(); - new ApplicationConfig(MesOptions.class); - new ApplicationConfig(MesOptions.class, MesActions.class); ...
ApplicationConfig config = new ApplicationConfig(...); config.parse(args); config.action(level);
Lors du new si les enums sont passées en argument, l'ApplicationConfig les utilise pour s'initialiser
Mise en commun de certains besoins ----------------------------------
Du coup, il est possible de mettre par exemple la methode Help dans ApplicationConfig qui retourne la chaine 'usage' a afficher.
Ce qu'il reste a faire ----------------------
Il n'y a pas grand chose a faire, vu qu'on a déjà une interface existante pour les options (OptionDef), il manque juste les alias.
-> version majeure de nuiton-utils car on casse une api.
Et il faut juste le mettre en place de cette façon dans les projets (surtout les libs) qui l'utilise et y penser pour les prochains.
A ma conaissance seul wikitty utilise ApplicationConfig -> donc rien à faire ? :)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Tue, 5 Apr 2011 22:51:19 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Je ne suis pas d'accord dans tous les cas.
Il peut être très bien de pouvoir utiliser ApplicationConfig (une surcharge en fait) comme un Bean, typiquement dans une application finale.
En fait ce qui me fait peur, est de ne pas pouvoir avoir une utilisation constante (toujours de la meme facon de AppConfig), et donc qu'il y ait des confusions pour les developpeurs. L'autre chose qui me fait peur, est qu'un jour on souhaite reutiliser un bout d'un programme final a la facon d'une librairie et qu'on y arrive pas parce qu'il a surchargé AppConfig. (on est d'accord que pour les libs la surcharge est a proscrire).
Le fait d'avoir des getter et setter c'est souvent plus pratique qu'un helper avec des méthodes statiques.
Je suis plutot d'accord avec ca, et ca me derange toujours un peu de faire du java objet et au final finir par de la programmation non objet. Mais dans le cas de AppConfig, je pense qu'il serait bien de voir si on ne peut pas faire en sorte de limite au maximum le besoin de surcharge de AppConfig. (On aura toujours des cas ou se sera plus optimal de faire cette surchage, mais si on arrive a faire en sorte que se soit l'exception et non la regle ce sera mieux pour la reutilisabilite du code produit qui se base dessus)
De plus avec un vrai objet de config, on peut aussi avoir une interactions avec des PropertychangeListener et c'est pas mal.
On doit pouvoir mettre ca au niveau de ApplicationConfig au moment du setOption pour qu'il leve le bon propertyChange comme si chaque option est une propriete. En plus l'avantage est que lorsqu'on sera obligé d'etendre la classe pour mettre ses propres methodes set, il n'y aura pas besoin de faire attention a leve les propertyChange, car normalement on aura appeler la methode setOption dans le code qui l'aura fait pour nous
Moi je suis vraiment pas convaincu de cette utilisation pour une application finale (en tout pour du swing qui utilise beaucoup la norme JavaBean). L'utilisation ensuite dans une librairie de cette surcharge d'ApplicationConfig ne posera jamais un problème car c'est toujours du ApplicationConfig.
Seulement si on n'en fait pas autant pour les libs (voir dernier paragraphe). Ou si un jour on essaie pas de mettre deux projets a fonctionner ensemble.
Suis-je clair ?
a peu pres, sauf si j'ai mal compris :(
Par contre pour les librairies oui il faut bien faire comme ça et donc pour moi y'a pas une manière universelle de faire.
C'est le point le plus important, et le point de depart de ma reflexion. Si on est obligé pour les libs, pourquoi ne pas essayer d'avoir une seule facon de faire pour eviter les erreurs et melanges -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 6 Apr 2011 15:25:56 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Tue, 5 Apr 2011 22:51:19 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Je ne suis pas d'accord dans tous les cas.
Il peut être très bien de pouvoir utiliser ApplicationConfig (une surcharge en fait) comme un Bean, typiquement dans une application finale.
En fait ce qui me fait peur, est de ne pas pouvoir avoir une utilisation constante (toujours de la meme facon de AppConfig), et donc qu'il y ait des confusions pour les developpeurs. Je pense que si le développeur n'est pas capable de différencier code une librairie et code une application finale, on peut pas faire grand chose en règle générale.
L'autre chose qui me fait peur, est qu'un jour on souhaite reutiliser un bout d'un programme final a la facon d'une librairie et qu'on y arrive pas parce qu'il a surchargé AppConfig. (on est d'accord que pour les libs la surcharge est a proscrire).
Peux-tu redonner un exemple qui fait que ça ne marcherait pas car là je me souviens plus du problème ?
Le fait d'avoir des getter et setter c'est souvent plus pratique qu'un helper avec des méthodes statiques.
Je suis plutot d'accord avec ca, et ca me derange toujours un peu de faire du java objet et au final finir par de la programmation non objet.
Mais dans le cas de AppConfig, je pense qu'il serait bien de voir si on ne peut pas faire en sorte de limite au maximum le besoin de surcharge de AppConfig. (On aura toujours des cas ou se sera plus optimal de faire cette surchage, mais si on arrive a faire en sorte que se soit l'exception et non la regle ce sera mieux pour la reutilisabilite du code produit qui se base dessus)
De plus avec un vrai objet de config, on peut aussi avoir une interactions avec des PropertychangeListener et c'est pas mal.
On doit pouvoir mettre ca au niveau de ApplicationConfig au moment du setOption pour qu'il leve le bon propertyChange comme si chaque option est une propriete.
En plus l'avantage est que lorsqu'on sera obligé d'etendre la classe pour mettre ses propres methodes set, il n'y aura pas besoin de faire attention a leve les propertyChange, car normalement on aura appeler la methode setOption dans le code qui l'aura fait pour nous
Moi je suis vraiment pas convaincu de cette utilisation pour une application finale (en tout pour du swing qui utilise beaucoup la norme JavaBean). L'utilisation ensuite dans une librairie de cette surcharge d'ApplicationConfig ne posera jamais un problème car c'est toujours du ApplicationConfig.
Seulement si on n'en fait pas autant pour les libs (voir dernier paragraphe). Ou si un jour on essaie pas de mettre deux projets a fonctionner ensemble. Mais le fonctionnement de base marchera toujours, je vois pas où est le
euh le gros désavantage de ta solution c'est qu'elle est pas du tout conforme à la norme JavaBean donc à proscrire à tout prix... moi je veux pas de ça Swing comprendra pas et en générale Java non plus :( C'est à ça que servent les getter, je pense qu'on s'éloigne un peu trop de la vision JavaBean, POJO et Java au final :) Donc is on veut les getter il faudra toujours surcharger ou déléguer, y'a pas de magie possible malheureusement, ApplicationConfig ne répond tout simplement pas à ce besoin. problème en fait ? Peux-tu nous redonner un cas où le problème arrive ?
Suis-je clair ?
a peu pres, sauf si j'ai mal compris :(
Par contre pour les librairies oui il faut bien faire comme ça et donc pour moi y'a pas une manière universelle de faire.
C'est le point le plus important, et le point de depart de ma reflexion. Si on est obligé pour les libs, pourquoi ne pas essayer d'avoir une seule facon de faire pour eviter les erreurs et melanges
Oui mais là les besoins sont très différents donc je pense pas que ça soit faisable et donc même pas souhaitable. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 6 Apr 2011 15:51:26 +0200 Tony Chemit <chemit@codelutin.com> wrote:
L'autre chose qui me fait peur, est qu'un jour on souhaite reutiliser un bout d'un programme final a la facon d'une librairie et qu'on y arrive pas parce qu'il a surchargé AppConfig. (on est d'accord que pour les libs la surcharge est a proscrire).
Peux-tu redonner un exemple qui fait que ça ne marcherait pas car là je me souviens plus du problème ?
On a une librairie A qui a un AConfig qui herite de ApplicationConfig On a une librairie B qui a un BConfig qui herite de ApplicationConfig On a une application C qui a un CConfig qui herite de ApplicationConfig C utilise A et B Si pour l'init de A on a la methodes: - init(AConfig config) Si pour l'init de B on a la methodes: - init(BConfig config) Lorqsu'on va venir avec notre CConfig qui vient de l'application, il ne rentrera pas dans le AConfig ni le BConfig. AConfig n'est pas assignable a BConfig qui n'est pas assignable a CConfig. Bien sur ils sont tous assignable a ApplicationConfig, mais il n'y en a nul part. D'ou ma volonté de n'utiliser que des ApplicationConfig pour que tous ce qui est ecrit en l'utilisant soit compatible entre eux. donc pour les libs c'est obligatoire de n'utiliser que ApplicationConfig (sinon elles sont difficilement reutilisable, a moins de passer a chaque fois par la creation d'un nouvel objet de config specifique a la lib avec tous les risques que la duplication entraine) et la perte de temps de creation d'objet. Pour les applications c'est moins vrai, mais si on peut faire uniforme, je prefere autant. Et comme ca on est aussi a l'abri de probleme d'incompatibilite entre application que l'on voudrait utiliser entre elle. Est-ce que je suis plus clair ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 6 Apr 2011 17:34:17 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 6 Apr 2011 15:51:26 +0200 Tony Chemit <chemit@codelutin.com> wrote:
L'autre chose qui me fait peur, est qu'un jour on souhaite reutiliser un bout d'un programme final a la facon d'une librairie et qu'on y arrive pas parce qu'il a surchargé AppConfig. (on est d'accord que pour les libs la surcharge est a proscrire).
Peux-tu redonner un exemple qui fait que ça ne marcherait pas car là je me souviens plus du problème ?
On a une librairie A qui a un AConfig qui herite de ApplicationConfig On a une librairie B qui a un BConfig qui herite de ApplicationConfig On a une application C qui a un CConfig qui herite de ApplicationConfig
C utilise A et B
Si pour l'init de A on a la methodes: - init(AConfig config)
Si pour l'init de B on a la methodes: - init(BConfig config)
Lorqsu'on va venir avec notre CConfig qui vient de l'application, il ne rentrera pas dans le AConfig ni le BConfig.
AConfig n'est pas assignable a BConfig qui n'est pas assignable a CConfig.
Bien sur ils sont tous assignable a ApplicationConfig, mais il n'y en a nul part. D'ou ma volonté de n'utiliser que des ApplicationConfig pour que tous ce qui est ecrit en l'utilisant soit compatible entre eux.
Ok ton exemple me parle. Merci.
donc pour les libs c'est obligatoire de n'utiliser que ApplicationConfig (sinon elles sont difficilement reutilisable, a moins de passer a chaque fois par la creation d'un nouvel objet de config specifique a la lib avec tous les risques que la duplication entraine) et la perte de temps de creation d'objet.
Pour les applications c'est moins vrai, mais si on peut faire uniforme, je prefere autant. Et comme ca on est aussi a l'abri de probleme d'incompatibilite entre application que l'on voudrait utiliser entre elle.
oui je vois bien ton point de vue et je le partage, tout en nuançant sur le besoin réelle dans une application finale qui peut-être très couplée avec sa configuration et être bien plus en interaction avec celle-ci. Dans ce cadre ApplicationConfig n'est pas auto-suffisant car non JavaBeans et donc non écoutable :( Et en plus se dire qu'une application finale va peut-être un jour devenir une librairie c'est tiré par les cheveux, si cela doit arriver, on fera alors le nécessaire pour dégager un module de l'application finale (ce qui devrait pas être bien dure si c'est en multi-module...). On en reparlera un jeudi soir si tu veux :)
Est-ce que je suis plus clair ?
Ah oui ;) merci -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
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 :() 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. des remarques sur cette approche ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
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
On Tue, 5 Apr 2011 17:33:46 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Ajout de méthode spécifique pour accéder facilement a une option ----------------------------------------------------------------
methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String
Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION);
En fait c'est idiot ces methodes, vu qu'on est sur une enum, c'est encore plus simple que ca: MesOptions.MA_JOLIE_OPTION.getValue(config) qui est l'equivalent de config.getOption(MesOptions.MA_JOLIE_OPTION); Donc en fait de compte pas beaucoup de plus value :( -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 6 Apr 2011 15:07:01 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Tue, 5 Apr 2011 17:33:46 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Ajout de méthode spécifique pour accéder facilement a une option ----------------------------------------------------------------
methodes pour acceder rapidement aux options si on le souhaite sur l'enum ex: - getMonOptionFichier(ApplicationConfig config): File - getUneAutreOption(ApplicationConfig config): String
Ces methodes feraient simplement: - return config.getConfigAsFile(MON_OPTION_FICHIER); - return config.getConfig(UNE_AUTRE_OPTION);
En fait c'est idiot ces methodes, vu qu'on est sur une enum, c'est encore plus simple que ca:
MesOptions.MA_JOLIE_OPTION.getValue(config)
qui est l'equivalent de
config.getOption(MesOptions.MA_JOLIE_OPTION);
Donc en fait de compte pas beaucoup de plus value :(
Si y'en a quand même une : le typage, non ? L'utilisation des generics est compliquée dans une enum. Le fait d'avoir des méthodes dédiées est une bonne chose pour moi et je préfère cette solution plutôt que des casts sauvage à chaque fois que j'ai besoin d'une option. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (3)
-
Benjamin POUSSIN -
Julien Ruchaud -
Tony Chemit