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

**Guybrush** · 27/09/2010, 17h45

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.

**sinok** · 28/09/2010, 10h00

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

**Guybrush** · 28/09/2010, 10h13

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.)

**sinok** · 28/09/2010, 11h56

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.

**bouye** · 30/09/2010, 00h15

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...).

**tchize_** · 30/09/2010, 09h26

+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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9

	
	Code  :
	Sélectionner tout -
	Visualiser dans une fenêtre à part
	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 });