> Les g�n�ralisations doivent se faire � partir de
> l'organisation des objets et
> des classes, et non pas sur des rep�rages � l'aide de constantes.
>
La dessus, mon avis est que l'organisation des classes graphiques
ne sera jamais un mod�le pur et qu'il faudra toujours plus ou
moins optimiser, ... Mais j'ai peut-�tre tort.
Enfin, il est vrai que si on prend le probl�me unitairement,
�a parait lourd d'utiliser des propri�t�s au lieu de m�thodes
attributs. Par contre, si tu te place dans l'optique d'un framework
ou m�me de la cr�ation de composants graphiques VRAIMENT r�utilisables,
l� �a peut avoir un sens.
>
> Il me semble que la question d'origine portait sur les propri�t�s /
> reflections. J'avoue �tre peu convaincu par le choix
> "propri�t�s", mais c'est
> le choix du d�veloppeur, il est le mieux plac� pour choisir
> ce qu'il faut !
> Par contre pour un choix propri�t�s / m�thodes, cela m'�tonne
> qu'il existe
> des situations o� l'on pr�f�re l'acc�s par propri�t�s.
La question de d�part �tait, je crois, comparer les performances
des deux solutions. Je voulais juste dire que dans 90% des cas,
l'acc�s � des propri�t�s reste tr�s correct au niveau des performences.
> Je subodorre que l'affichage lui m�me (ce qu'il y a dans le
> "paint") se passe
> relativement rapidement.
Mouai, j'en suis pas persuad�, mais comme je ne suis pas sp�cialiste,
je me tais.
> Par contre la grosse perte de temps
> se situe dans
> toute la gestion des je ne sais combien d'objets utilis�s
> pour le pr�parer.
L'erreur (par exemple pour les TableModel) se situe souvent dans le
cas o� on cr�e des objets dans le getValueAt.
Sinon, d'exp�rience, je t'assure qu'utiliser des HashMap dans le
getValueAt pour r�cup�rer les valeurs fonctionne tr�s bien, m�me
avec beaucoup de donn�es.
Olivier
