Salut !
> Pour conclure ce petit troll de fin de soir�e, quand je peu �crire 10
> lignes de code au lieu de 100 avec un peu de java.lang.reflect, je
> n'en prive pas, car 10 lignes restent de toutes fa�ons plus lisibles
> et maintenables que 100 que je ne peux m�me pas visualiser en m�me
> temps sur mon �cran.
Le seul probl�me est que pour mod�liser l'utilisation de l'introspection,
tu vas quand m�me avoir du mal.
En fait, il me semble qu'il faut s�parer les utilisations de cette m�thode
dans un cadre fonctionnel et dans un cadre technique.
Il faut compl�tement proscrire l'introspection quand tu es dans une classe
fonctionnelle, qui doit �tre mod�lis�e et correspondre � un processus m�tier.
Je rappelle qu'un des int�r�ts de Java (je lu �a qqpart, c'est pas moi qui le
dit) �tait d'�viter d'�crire du code non fonctionnel (malloc, free, ...)
Comme l'a tr�s bien dit Nicolas, une ou deux petites interfaces (c'est pas tr�s
long � �crire) et on peut souvent r�pondre au probl�me.
Enfin, apr�s cela, tu as des classes techniques (gestion des messages d'erreurs,
persistance, ...) qui peuvent t'obliger � utiliser un tel m�canisme. Et l�,
l'introspection est autoris�e et m�me encourag�e.
Olivier
>
> --
> Laurent Martelli http://jac.aopsys.com/
> [EMAIL PROTECTED]
http://www.bearteam.org/~laurent/
