[Langage] Classe avec un grand nombre de méthode

Bonjour,

Je dois créer un objet contenant plusieurs centaines de membre. Chacun de ces membres doit avoir un getter et un setter.
Si ma classe compte 500 membres, je vais donc devoir définir 500*2=1000 méthodes (pouvant elles-même être redéfinit et/ou surchargées dans les classes dérivées)
Ma question est donc la suivante : est ce problématique d'avoir autant de méthodes dans une seule classe ? Je parle uniquement en terme de performances, je suis conscient que ce n'est probablement pas l'idéal en terme de conception mais je n'ai pas le chois sur ce point.
Je précise que ma classe de base sera ensuite dérivée en de nombreuses sous classes et que mon programme peut manipuler simultanément plusieurs centaines d'instances de ces classes.

Et ensuite tu te retrouves avec des monstres du type des classes Swing à la maintenabilité plutôt douteuses, voir pas évidente du tout.

Bon sinon en ce qui concerne les limitations de la VM sur ce plan là: http://java.sun.com/docs/books/jvms/...doc.html#88659

comme je l'ai indiqué, je suis bien conscient que ce n'est pas une conception idéale...

Je ne cherche pas connaitre les limitations (je n'atteindrais jamais le nombre max de méthodes) mais à savoir quelle est le coût de ce type d'architecture en terme de performance (occupation mémoire, temps de création des objets, vtables, etc.)

Il faudra très probablement faire attention à ton PermGen Space, qui correspond à l'endroit où est stocké le code sous sa forme compilée. Ensuite tu dois toujours être bien loin du volume utilisé par des monstres du genre Eclise/Websphere & cie eu niveau du volume de code occupé. A priori pas de problème en soit.

A la rigueur plutôt que de décrire chacun des 500 membres de la classe je délèguerai plutôt le stockage a une Map<String, Object> ce qui permet assez facilement d'automatiser la gestion de l'envoi de propertyChange(PropertyChangeEvent). Mais bon ça oblige a gérer certains cas spéciaux comme la pré-initialisation de membre sensé être des littéraux (pour eviter des NullPointerException).

Libre a toi après d’écrire les 500 setters + 500 getters mais je pense que tu auras du mal a aller aussi loin (déjà moi au bout de 10...).

+1 pour la map. Puis après rien ne t'empeche de faire un générateur de code pour les getters / setters qui vont se baser sur la map. au moins, tu évitera les 500 lignes de déclaration de champs dans la méthode.

Si tu as déjà une interface avec les 500 getters / setters, tu peux créer tes instances, éventuellement, avec une classe Proxy:

Code:

---

1 2 3 4 5 6

Code: 123   InvocationHandler handler = new MyInvocationHandler(); // handler qui convertis getters/setter en un appel à une map MonInterface f = (MonInterface) Proxy.newProxyInstance(MonInterface.class.getClassLoader(), new Class[] { MonInterface.class },newInstance(new Object[] { handler });

---

Citation:

---

Envoyé par bouye

Libre a toi après d’écrire les 500 setters + 500 getters mais je pense que tu auras du mal a aller aussi loin (déjà moi au bout de 10...).

---

Bon ensuite il y a les flemmards qui laissent l'IDE les générer ceux là...

Mais bon, rien qu'écrire les 500 variables, c'est déjà über pénible...

cut & paste depuis le document de spécification + un coup de regexp pour nettoyer? :p Je serais curieux de voir la gueule des noms de champs. Ca va de aa à zz? :)

encore une fois ma question ne portait pas sur la qualité du code mais bien sur les performances. Je n'entrerais pas dans le détail de l'implémentation mais je suis bien obligé d'avoir X membres avec autant de getter et de setter (il y a un système d'annotation du chaque méthode qui rend leur création manuelle inévitable).

je reformule donc ma question : est ce que manipuler des objets contenant un très grand nombre de méthodes avec surcharge et redéfinition à plusieurs niveau de la hiérarchie pose un pb en terme de performance, en particulier au niveau de la vtable : rapidité de création des objets, occupation mémoire, etc.

difficile à dire. Oui les méthodes seront plus lente à trouver dans la vtable de part son nombre de clés. Non ca ne devrais pas être critique car le JIT, lorsqu'il aura convertis le code en natif, sera affranchis des recherches dans la vtable.