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