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